-
----
# 2022-12-06
- Demo of java control plane
- Zach and project status
- Go Control Plane CI
# 2022-11-15
- Kubecon/Envoycon updates
- Implementation research
- types of implementations
- libraries vs. end-user control planes
# 2022-08-23
- Test case check-in
- Istiod/Pilot exploration
- Hard to isolate pilot
- avenues for help suggestions
- Schedule SoW revisit for next meeting?
# 2022-08-02
- second implementation explorations
- priority of this in SOW?
- last test cases
- begin rest implementation?
# 2022-07-12
- simple refactor and gcp update
- check in on TODO tests
- 2nd example implementation?
# 2022-06-14
- improved valdidation (no sql!)
- delta tests implemented for CDS,LDS,RDS,EDS
- simplified adapter api
- 0.5 roughly done, per SoW
- moving to "0.75"
- researching the TODO tests in xds test cases doc
- researching implementation strategy for 1.0 requirements
# 2022-05-23
- update on delta test progress
- new db for validating test steps

# 2022-05-03
- Delta Cases
- First 3 tests of 7 done
- 4th test in progress
- Have questions
- AI: Open an issue on Go control plan bug - Zach

# 2022-04-12

- Meeting canceled

# 2022-03-22
- Logging and testing update
- Unsubscribe from some resources...WORKING!
- Unsubscribe from all resources...maybe working
- Delta Cases

# 2022-02-28
- demo: Logging improvements, update config & printing out results
- Adi: AI:More feedback, like test name while running to show progress
- AI:Build testing suite for the test suite
- AI: Test scenarios from Mark, Zach with also take a swing at it.
- AI: Pair with Zach & Alec

# 2022-02-01
- demo: Variants support in test runner
- Functionality is really good!
- Octal may be too opaque
- change flags to be more readable - Mark
- List of List of flags?
- Assign sotw-incr, sotw-agg, comma separated list
- AI: environment var driven / more verbose
- Now ready for incremental tests?
- Zach : ready for collaboration
- AI: come up w/ some ideas, pass onto Mark for review
- Demo ads support and ADS Only Test
- "Client can subcribe to multiple services via ADS"
- When, Then repeated service + other service...
- Ensuring this isn't opaque: "And the service never responds more than necessary"
- this checks that the client is acking every correct response, but the server is not responding to the ack.
- e.g. there should be more requests than responses
- What we want in principal and what is being described is the same
- I think counting vs verifying each response is ok.
- With regards to stale nonce handling... needs some time to think through this more fully - AI MARK
- we may want to structure this to happen automatically (most of the time, with a test specific exception)
- This approach is good overall.
- Debugging question
- When I get this error, how easy is it to find what the problem is?
- > Add `--debug` adds full logging (e.g. each request and response step is logged)
- Overall lifecycle debug should be available
- Needs some improvement on logging, add external support(e.g. to debug tests via a proxy)
- see everything that is sent and received
- (ADI: this is a good start)
- Mark: Logging everything sent + received is a great base debugging tool
- Zach: We also cache all these events within the runner
-

- current test cases check-in
- Come up with incremental test cases
- our our list of TODOS: Incremental support is the most important next step.
- the other TODOS are mostly edge cases
-
- next steps
- 0.5 still needs incremental xDS
- add logging to disk
- ensure code is clean and mnimal
- Incremental tests cases need to be defined

----

# 2022-01-11
## Discussion
- We are Back!
- Meeting with Kong
- Expectations for 2022

----

# 2021-11-30
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Mark D. Roth (grpc/google)
- Alec Holms

## Discussion
Review of the work done by the ii team with Alec & Mark.

----

# 2021-11-07
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Mark D. Roth (grpc/google)

## Discussion
- Implement RDS tests
- changed runner to better add services
- Added RDS as example to existing tests as possible
- Followup on unusbcribing tests
- not passing for RDS as well on go-control-plane

----

# 2021-10-11
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Fuqiang Gao (google)
- Mark D. Roth (grpc/google)

## Discussion:
- LDS/CDS tests written
- new format utilizing tables
- discuss issues with [Tests 7 & 8 (PR#29)](https://github.com/ii/xds-test-harness/pull/29)
- Possible bug: [Multiple listeners is not working with Golang XDS Client · Issue #349 · envoyproxy/go-control-plane](https://github.com/envoyproxy/go-control-plane/issues/349)
- Possibly Fix? (AI: let's take a look, maybe jam out in a couple days?)
- Separate Stream for each resource
- non-aggregated case
- go-control-plane may be envoy focused
- no effort to support GRPC client
- Let's figure out what's happening in go-control-plane VS making assumptions
- [ ] AI: Merge the test as is (with failed test)
- With RDS/EDS may need to adjust the test cases a bit
- Suprising behaviour in go-control-plane... that linkages between layers are enforced
- data model isn't clear
- [ ] AI?: Get someone from go-control-plane
- what is the model you are approaching from
- do we need to decouple
-
- REVIEW transport-protocol-layer
- what is the wire protocol
- subscribe / unsubscribe
- payloads are opaque blobs
- REVIEW data-model-layer
- field specific reference
- de-reference
- layer above transport

# 2021-09-20
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Fuqiang Gao (google)
- Mark D. Roth (grpc/google)
- Adi Peleg (envoy/google)

## Discussion:
- Updates on the Test Runner

Make test more verbose with more logging

## Mark
wrt Wildcard expansions *
A and B Exist
C get's added
Resource subscription is not affected by server response

## Zach
A & B Exist
If subscription is wildcard
How do I ack
Mark: You don't need to adjust the ACK, based on the response. (This works! Test case 3 can be setup well now -zz)

## Style Question
IS the way in which that resources is updated.
Resource A connect timeout is adjusted,
whatever the adjustment is, can we observe,

Clarification: Does it matter the field? (Mark: NO) The contents are opaque with regards to the transport protocol. Just change something.

Adi: xds-incremental mode, you'll have a pair resource version.
With any of these test
We need to state somehow we are running in SOW vs Delsta

IN the test prep, we noted we need to move onto incremental.

Fuqiang: Are any of these tests / scenarios generating... some of these can be reused for delta?
(zz) Yes. The same type of function, but a Delta in front (maybe a taG?) to make them generic?

A lot of functions are written, because the structure is different, we'll need to adjust the regexp pattern.

## Adi
When we start seeing more xDSs coming into play ADS will be more relevant.

- Mark we will wan to run them for both

## AI: Fuqiang
Add a Q4 OCR to write an adapter for Traffic Director!! Importing the test suite / running internially or exposing the adapter publically? (Mark: Whatever is easier)

For the sandbox, we can import the opensource into google.

# 2021-08-30
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Mark D. Roth (grpc/google)
- Adi Peleg (envoy/google)

## Recording
https://us02web.zoom.us/rec/share/uJ_r4GhunPpdyTJvjA_lWODKopra9fmzDwV2ZiZXlQsPNGGe__pza3-BHHvMyjHV.RekPELkKcItPe84w Passcode: vThR#U7L
## Fred
> "All of us, at some time or other, need help. Whether we're giving or receiving help, each one of us has something valuable to bring to this world. That's one of the things that connects us as neighbors--in our own way, each one of us is a giver and a receiver."
> : Fred Rogers
## Positive Pointing
[](https://www.youtube.com/watch?v=YLO7tCdBVrA)

## Discussion:
- Updates on the Test Runner
- Version and Nonce might be great variables
- Test Case:
- client sends a stale nonce, server should ignore
- test case should be able to control everything in the client request
- For each test case, there may be unique steps
- we may begin to see the abstract patterns
- let's not pre-optimize
- Keep in mind, general-rule
- extract arbitrary details from responses we recieve
- directly set details for everything we sent
- (ie use a response detail in a sent detail )
- ie. Nonce from previous recieve
- saved as the default nonce to send in next
- The nonce that the server sends : 1
- Client Another request
- Server sends nonce 2
- Client sends nonce 1
- Server should ignore nonce 1
- Another thing worth considering
- exact next response should be...
- eventual consistency model means that eventually we have the update we want
- ability to look back and extract the field that you want from the history...
- Tests we have ported over
- update on test cases (thank you @Mark!)

# 2021-08-02
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Mark D. Roth (grpc/google)
- Fuqiang Gao (google)
- Snow Pettersen (Lyft)

### Discussion:
- List of test scenarios - xDS

# 2021-07-12
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhgans (ii)
- Adi Peleg (envoy/google)
- Mark D. Roth (grpc/google)
- Fuqiang Gao (google)

## AI from last meeting:
- Feedback on review of the [Design document](https://github.com/ii/xds-test-harness/blob/2beb523a09d8c313f6e54cce8eade25f8149ddb0/docs/design-doc.md)
- Cover the SoW and OKRs to ensure common understanding
- Public recording of xDS conformance meetings

- AI: List of all test scenarios should be created by xDS team.
- Start with SoW
- assigned to Fuqiang Gao (google)

# 2021-06-21
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Caleb Woodbine (ii)
- Adi Peleg (envoy/google)
- Mark D. Roth (grpc/google)
- Harvey Tuch (envoy/google)
- fuqiang gao (google)

## Progress for 2021-6-21
- Ready for Review / Signoff
- [ ] [design doc](https://github.com/ii/xds-test-harness/blob/2beb523a09d8c313f6e54cce8eade25f8149ddb0/docs/design-doc.md)
- [ ] objective 3 poc
- Clarification / Requests
- Are we responsible for launching the target?
- Mark: What is the typical setup / do we need to start the target?
- Harvey: Could run Go control plan and that might be sufficient
- Or do a shim and run against it
- We would likely not use the cloud API
- SoW of trace based
- Snap shot should work with Go control plan

- Mark: Do we currently have snapshot not add /remove resources
- Need an adapter that provide the API to talk to the target that is being tested
- Harey: Home work to see if it make sense for deputy to recieve SoTW test or a more incremental trace based API - Add/remove
- Could test trough a snapshot or trace arrangement
- Both can work
- Snapshot should work with Go Control plan
- Mark: trace is harder but more effective it the target understand how to apply the deletas.
- TD (Traffic Director -google)would likely be more comfortable with snapshot approach
- Adi: Side effect of trace and cleaning-up after the test should be considered
- Mark: SoTW version is a funtction of the resources and not communication on the wire, related to the snapshot version
- Harvey: Use of system version as a logical clock?
- 0.5 go with what ever would work with go control plan
- Does not have to use xDS relay if Go control plane can manage
- Would be a win to exclude xDS relay
- Go control plan and Java control plan cover most use cases
- Would have an adapter of both Go and Java
- Imported to have the correct framework
- HH: from our understanding there need to be an xDS target to hit and an xDS adaptor that have the funtions, but we understand now is that we need to write a adapter for Go control plane.
- Harvey: Must write an adapter for Go and Java control plain.
- All the testing will be done where every thing is running already before starting the test.
- What is important to having the right famework: APIS, adapter proto and the test runner.
- Mark: Question round adapter API: Snapshot vs. "add/remove resource"
- "add/ remove" should be better, but this can be handle though control planes
- Gao: how is configs injected - Mark - up to the adapter
- hh: should we write different test for SoTW and Delta
- Mark: test must he written for both SoTW and Delta
- Would be similar but separate
- SOW Milestones

- Working on
- delta protocol in test runner
- refine design document on feedback and delta

- [xDS conformance test suite: Objectives and Key Results](https://hackmd.io/ZKiBO7XKRMWjpttvbYAHbg?view)

- Next meeting:
Cover the SoW and OKRs to ensure common understanding
Feedback form review of the Design document

# 2021-06-07

- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
- Caleb Woodbine (ii)
- Adi Peleg (envoy/google)
- Mark D. Roth (grpc/google)
- Fuqiang Gao (Envoy/google)
-

## Agenda

## Progress for 8-6-21
- Working on Objective 3: initial framework
- removed shim, no longer a requirement.
- better parsing, so tests can be all yaml examples
- working on clean state between test scenarios, and best testing of streams.
- Next up
- Design Document, rough outline
- EDS Documentation Improvement
- Questions for Tomorrow
- confirm ability to wipe state of instance without restarting xDS server.

Updates:
- This in no longer a shim!
- Cleaner interface is just an adapter API
- (however the target sees fit)
- Tests are written in Gherkin w/ embedded yaml
- Decoded the resources (anytype)
- YAML+JSON hash from last test hard to write/read
- Stuck on Go side in passing the streams
- Adding ii golang resources

Help Wanted:
- Forcefully Reseting State / Version Approach
- [aTargetSetupWithSnapshotMatchingYaml()](https://github.com/ii/xds-test-harness/blob/dstream/acknack_test.go#L60-L74)

- Adding another ii resource for Golang - Caleb
- In the case of a single test the current application is working
- But wanting to be able to run tests in any order.
- Therefore a resource "reset" is needed
- Test would be ended by closing the steam

- Mark - xDs listner and cluster resource
- All resouces you subscribe to must be listed
- Resetting the go control plane would likely be the correct way to "reset"
- Adi - make sense to have the target set at the beginning of the test
- Mark - resetting vs. running in parallel should be considered
- xDS do not support namespaces
- Wild card queries should run in a seperate "sandbox" environment
- xDS severs in the wild could be set up differently
- xDS is for getting data from the management servers
- We do not have to support what every implementation in the wild is doing.
- We might want to figure out what is the common paterns we want to support.
- HH - what would be the standarized parts to test.
- Adi - parallizing test would be a problem for wildcards and we need to think how we want to test it.
- Mark - The new xDs naming scheme would resolve the wildcard issue with "namespacing"
- HH standardising configuration would help to support conformance, if is is compatible with xDS
- Would be helpful to determine what the world is shaped like for users of xDS to determine use cases.
- Mark - The goal for the test suite is to determine if their management server was implemented correctly
- Lowest common denominator, run test sequential with a "fresh" state for every test that is run.
- Comment test application, but with to style for working either is parallel or in sequence
-

----
# 2021-05-18

- Adi Peleg (envoy/google)
- Mark Roth (envoy/google)
- Fuqiang Gao (Envoy/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)

## Agenda
- Test Harness PoC Demo
- DEMO TIME
- test-harness - https://github.com/ii/xds-test-harness
- [tests/features/acknack.feature](https://github.com/ii/xds-test-harness/blob/main/tests/features/acknack.feature)
- [api/adapter/adapter.proto](https://github.com/ii/xds-test-harness/blob/main/api/adapter/adapter.proto)
- [tests/acknack_test.go mat](https://github.com/ii/xds-test-harness/blob/main/tests/acknack_test.go#L153-L166)
- Questions:
- What are the adapter / shim?
- Adapter is meant to set the state
- target that has cluster foo
- adapter is used to inject resources
- How you need to interact with that implementation to feed data into it...
- load this stuff into the target
- SHIM is implemented by the test target
- it's implementation specific plugin for the adapter
- why do you need a port to connect to it?
- Could be just a library with an interface
- What logic is on the adapter?
- return stuff as the test-runner wants
- What logic is on the shim?
- just expecting snapshot to update target
- Mark Roth : For individual tests to be uderstandable, they will have all the data in the test definition.
- all you need that is target specific is loading the target
- Ensure everything that is used for a specific test
- Does framework have a series of steps
- create a stream between test-runner and target
- stream is passed to next
- Are there going to be abilities to
- handling race conditions in the protocol
- catching it at the right moment
- run the same test case 1000 times
- see how race conditions properly
- (we've discussed, but not part of 0.5)
- ADS has race conditions
- most servers will ignore requests from client with stale numsys
- server sends nonce one, and responsed
- but before server sends none two, client sends nonce one
- edge cases based on order in what it sees
- has to cover all of these possibilities
- Can't reach into the servers implementation
- Adi
- timeouts and exceptions
-
- Accessing Resources Shortcut
- the any has a go api for decoding
- Maintaining stream between scenario steps
- godog library
- Define an target ignostig rpc interface for
- add/remove resource to target
- for each target implementation

----
# 2021-04-27
- Adi Peleg (envoy/google)
- Harvey Tuch (envoy/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)

## Agenda
- Progress from last week
- rough test cases from xDS transport docs
- Adi pair - focus is correct for 0.5!
- a couple writeups
- internal documentation
- questions from adi 1on1
- conformant error handling?
- unclear about client side errors
- Does the server sends an error message.
- If the server sends something wrong...
- the test fails
- However we shouldn't test for errors on the server?
- Adi: If the server send something wrong the test should fail. But do not check for errors in resources
- If the client ids requesting a non-lister resources without names.
- Should the server respond in a certain way?
- Harvey: we should test expected behaviour
- Adi: Expected behaviour is that the server will not send a response. (no error message send, time out on client side)
- Harvey: When there is no explicit return it should still feature as a test...
- Adi: If it does return something when a service should not exist, then there is a problem
- docs on EDS?
- unclear exactly what EDS looks like in a config
- :boom: on understanding of levels of dynamic configuration
- Current configuration docs are a bit indirect
- says it should be configured
- links to Go control plane
- Need more context
- Start in earnest:
- Heading with a title and no content (CDS)
- Write-up of a more in depth of EDS and what it's intended to do (Harvey: That would be great!)
- [Objectives and Key Results](https://hackmd.io/ZKiBO7XKRMWjpttvbYAHbg?view)
- Inital Test Written : Around keep alives
- In xDS Protocol Overview
- explicit note
- implementations where updates might be sent
- Harvey: Have a parameterized test
- every N seconds we expect no update - check and prevent spin loop
- verify that it's not returning immediately
- it's going to cause that envoy to have very terrible conformance characteristics
- Zach: Good overview for test adapter and state machine
- goes beyond how you would define this as a test case
- to how does godog and a syntax lend it to implementing something like this
- Harvey: Confidence of seeing this is godog (or other) will give us confidence that this framework will cover what we are shooting.
- Hippie: Getting consensus on the objectives / concepts and looking forward to next objectives in every meeting to have confidance on the patterns. That would make reuse of code more efficient.
- Harvey: We are looking to ii to drive the test cases as you are going though the docs.
- It will be more efficient if ii drive and enumerate test cases
- We will review which test cases make sense.
- Adi: As the xDS protocol still evolve more test cases will come up after 0.5

## AI:
- Create EDS documentation
- PR's for missing documentation / broken or missing links
- PoC of first test to show planned test infra - Godog
- Trim down number of key result per Objective 3 - 6, one test per major area

# 2021-04-20

## Attendees
- Adi Peleg (envoy/google)
- Harvey Tuch (envoy/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)

## Agenda

### Progress from Last Week
- 1on1 with Adi (thank you Adi!)
- client demo
- sends discoveryRequest, logs discoveryResponse
- change resources, new response sent out.
### Questions from last week
- Measuring "doneness" of 0.5 step 1
- "Audit and refine existing xDS documentation with API shepherds. Build contractor understanding of xDS and improve documentation. This will be a time boxed exercise, e.g. 1-2 weeks."
- Proposed metrics:
- client communicating with xDS server
- small set of test cases, casually defined
- documentation showing the implementation of these test cases with the client
- distinction on "endpoints" for endpoint discovery service

## Summary

ii demo the test runner and test adapter.
- The test shim would take the initial config file and update the clusters in a controlled way and would then measure the structure of the responses received back.

The idea with Obejctive 1 of 0.5 was to get ii to the point where Xds make sense.
Being comfortable what test case should look like it is OK to move onto test a first test case.

Line-by-line analysis of the documentation would be a Envoy goal, but only after a number of tests was written. (and increase understanding is built)

Go thought the xDS protocol, Understand all the headers
ie. Unsubscribing from resources, requesting mulitple resourses
It there is blockers to understanding it should be addressed early. Also as part of doc review effort.

Godog/Cucumber/Gherkin - should be able to handle HTTPS race conditions and nonce

## AI:
- List headers and test cases for each header
- Present OKR's at next meeting
- Seeing a test running detecting a "fail" should be a next milestone
- Continue with .org mode docs to show progress
- Godog/Cucumber/Gherkin test runner options - Modeling nonce

# 2021-04-13

## Attendees
- Adi Peleg (envoy/google)
- Harvey Tuch (envoy/google)
- Mark Roth (grpc/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
## Agenda

### Progress from Last Week
- set up and annotated go control plane work
- learning session with ii to distribute knowledge
- attempted to set up logical dns in custom go control plane
### Questions from last week
- Distinguishing target from message
- Additional resources for EDS?
## Action Items

## Summary
In the MVP we are trying to test the behaviour of servers and not the client - Envoy

Trying to validate behaviour of Go control plane / XDS relay
The target is management servers and control planes to check if what was built to work with Envoy is correct

The property of Go control plane of XDS being tested must make sense.

Testing management server implementation can be done with a "transparent" client implementation where you can see the communication with the XDS client (Client send the requests to the Go Control plane) and the server.

Diagrams in the [XDS protocol overview](https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol.html):
The response, sequince, communication time can be evaluated.

Envoy xDS in gRPC there is [code](https://github.com/grpc/grpc-go/blob/master/xds/internal/client/client_test.go) for a separate client layer that can be forked to use as a basis for building the client. This can then be use validation of responses.

Note: gRPC implementation only "speak" aDS but on "wire protocol" is the same.

Endpoint discovery service:
Details of what is in the resource in not important at the moment
The ask is that clients and servers can:
- Distribute resources back and forth following the intended protocol
- Ack and Nack
- Handle races
- Handle the nonce

Contents of the resource shipped does not matter, can be "Hello Work", "Foo", "Bar" etc. If versioning is used and the contents of the resource change it can be track by the name field with a version for tracking.

----
# 2021-04-06
## Attendees
- Adi Peleg (envoy/google)
- Harvey Tuch (envoy/google)
- Mark Roth (envoy/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
## Summary
* A control plane can choose the version it would return (this relates to API versions, like choosing between k8s 1.20 and 1.21)?
* Define the test harness to program the Control plane in a way that you know what resources it would return.
* Test harness is a contract between test infrastructure and the implementation.
* Qualifying resources ie. I have resource foo, and I am updating to bar
* Only if you set the resources you can make guarantees about what would be returned.
* If you have a system without those guard rails and resources are created dynamically on the fly, then the is no contractual obligation where the test can required to go back to a previous resource.

Test harness work both ways:
1. One way you tell the service manager something or
2. It can also tell you something ie. In an ACK/NACK sequence, it can report what was the last transaction it has seen.
This would be useful to track in order to assert properties correctly.

The test harness should be flexible enough that it could be used in either direction. Then tell it how to respond in order for you to be able to probe either way for testing.

Way to think about XDS servers:
- They have a control plane and configuration plane
- The testing must test the CONTROL PLANE and not the configuration plane
- There is no notion of conformance for the configuration plane as it can be created in multiple ways.

Step up a configuration plane per test and focus on the control plane expectations and the configuration is part of the test harness framework:
- Set up a very simple configuration
- The semantics of the configuration is largely irrelevant
- The aim is to understand how the control plane is serving up the requested resources.
- Add the expectation to be able to sent and receive.

[Code example:](https://github.com/grpc/grpc/blob/4d4ee609c144fd2cbee4f42dedacf4c9a92f1674/test/cpp/end2end/xds_end2end_test.cc#L474)
- Code used in a gRCP++ implementation
- RPC service on a gRCP
- Fake ADS server used for e2e tests.
- It can be used to set and unset resource versions
Can request resource by version and see how the client behaves

Documents referenced:
https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol.html?highlight=ack#ack

----

# 2021-03-23

## Attendees
- Adi Peleg (envoy/google)
- Harvey Tuch (envoy/google)
- Zach Mandeville (ii)
- Hippie Hacker (ii)
- Riaan Kleinhans (ii)
## Agenda
### Confirm Start Date for project
- Work will begin in earnest on 6 April, NZT.
- This will be first full week in April and it was agreed that starting work on April Fools would not be auspicious.
### Confirm weekly meeting schedule for April
- The current meeting time of Monday, 5:30pm, EDT worked for all attendees of the call.
- Zach will send out a recurring event at this time for the month of April
### Establish preferred communication channels/styles
- Slack is the way to go
- A channel was created by Adi for us to gather in.
### Discuss beginning exercise
- Recommendation to focus on ADS and to pick a resource type.
- As a test case, confirming the expected behaviour in ACK/NACK and the resource version string was considered a good idea.
- Recommended to start on a simple test and established server, like the xDS relay.
### Open Questions/Comments
#### Work Rhythm
- Discussed preferred work units and timespans, e.g. whether ii works in 2 week sprints or some other means.
- ii's work rhythm is based on project. With this project, for the moment, it was good for weekly check-ins as the unit of work gets more defined.
- regardless, it will be good to establish some initial internal milestones to be able to track progress toward the 0.5 milestone
#### Documentation
- briefly discussed documentation and that PR's are welcome to improve the explanation of concepts or to find where documentation is lacking.
## Action Items
- setup slack channel @adi
- setup recurring meeting @zach