PB-159: remove weights from gRPC messages #298

little-dude · 2020-02-14T14:41:53Z

References:

https://xainag.atlassian.net/browse/PB-159

Needs to be merged along with:

Summary:

Remove the weights from the gRPC messages. From now on, weights will
be exchanged via s3 buckets.

The sequence diagram below illustrate this new behavior.

At the beginning of a round (1) the selected participants send a
StartTrainingRound request, and the coordinator response with the
same StartTrainingRoundResponse that does not contain the global
weights anymore.

Instead, the participant fetches these weights from the store (2). S3
buckets are key-value stores, and the key for global weights is the
round number.

Then, the participant trains. Once done, it uploads its local weights
to the S3 bucket (3). The key is <round_number>/<participant_id>.

Finally (4), the participant sends it's EndTrainingRequest. Before
answering, the coordinator retrieves the local weights the participant
has uploaded.

Important note: At the moment, the participants don't know their
ID, because the coordinator does not send it to them. Thus, they
currently generate a random ID when they start, and send it to the
coordinator so that it can retrieve the participant's weights. This is
why the EndTrainingRoundRequest currently has a participant_id
field.

    P                                C                      Store
1.  |   StartTrainingRoundRequest    |                        |
    | -----------------------------> |                        |
    |   StartTrainingRoundResponse   |                        |
    | <----------------------------- |                        |
    |                                |                        |
    |                Get global weights (key="round/global")  |
2.  | ------------------------------------------------------> |
    |                         Global weights                  |
    | <------------------------------------------------------ |
    |                                |                        |
    | [train...]                     |                        |
    |                                |                        |
3.  |       Set local weights (key="round/participant")       |
    | ------------------------------------------------------> |
    |                               Ok                        |
    | <------------------------------------------------------ |
    |                                |                        |
4.  |   EndTrainingRoundRequest      |                        |
    | -----------------------------> | Get local weights (key="round/participant")
    |                                | ---------------------> |
    |                                | Local weights          |
    |  EndTrainingRoundResponse      | <--------------------> |
    | <----------------------------- |                        |

At the end of the round, the coordinator writes the weights to the s3
bucket, using the next upcoming round number as key (see the sequence
diagram below).

P                                C                      Store
|   EndTrainingRoundRequest      |                        |
| -----------------------------> | Get local weights (key="round/participant")
|                                | ---------------------> |
|                                | Local weights          |
|  EndTrainingRoundResponse      | <--------------------> |
| <----------------------------- |                        |
|                                |                        |
|                                | Set global weights (key="round+1/participant")
|                                | ---------------------> |
|                                | Ok                     |
|                                | <--------------------> |

Implementation notes:

Initially, we thought we would be using different buckets for the
local and global weights. But for now, we use the same bucket for
local and global weights for now
We currently store the global weights under different keys. It turns
out that this brings un-necessary complexity so we'll probably
simplify this in the future
For now, the coordinator doesn't send any storage information to the
participants. Thus, the participants need to be configured with the
storage information. In the future, the StartTrainingRoundResponse
could contain the endpoint url, bucket name, etc.

Reviewer checklist

Reviewer agreement:

Reviewers assign themselves at the start of the review.
Reviewers do not commit or merge the merge request.
Reviewers have to check and mark items in the checklist.

Merge request checklist

Conforms to the merge request title naming XP-XXX <a description in imperative form>.
Each commit conforms to the naming convention XP-XXX <a description in imperative form>.
Linked the ticket in the merge request title or the references section.
Added an informative merge request summary.

Code checklist

Conforms to the branch naming XP-XXX-<a_small_stub>.
Passed scope checks.
Added or updated tests if needed.
Added or updated code documentation if needed.
Conforms to Google docstring style.
Conforms to XAIN structlog style.

References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<participant_id>/<round_number>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="participant/round") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="participant/round") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="participant/round") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round + 1") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc.

xain_fl/coordinator/coordinator.py

References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<round_number>/<participant_id>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does not send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round/global") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="round/participant") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round+1/participant") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc. handle review comments

References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<round_number>/<participant_id>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does not send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round/global") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="round/participant") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round+1/participant") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc.

atymoshchuk · 2020-02-17T15:31:17Z

Please rebase this branch

little-dude · 2020-02-17T15:35:11Z

Please rebase this branch

I'll probably wait a little because there are other PRs in the pipe that will create more conflicts. The PR is reviewable as it is anyway.

References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<round_number>/<participant_id>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does not send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round/global") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="round/participant") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round+1/participant") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc.

tests/store.py

xain_fl/coordinator/coordinator.py

finiteprods

looks good, just a few minor issues / questions. on a more general note, it does not look to me too difficult to have direct weights transfer (the previous behaviour) as just a "special case" of the present one. But this can be a separate issue.

tests/conftest.py

xain_fl/coordinator/coordinator.py

tests/test_coordinator.py

tests/test_grpc.py

References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<round_number>/<participant_id>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does not send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round/global") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="round/participant") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round+1/participant") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc.

Co-Authored-By: kwok <kwok.cheung@xain.io>

little-dude · 2020-02-20T08:17:48Z

I addressed the reviews and rebased.

finiteprods

all good, thanks.

rsaffi · 2020-02-20T08:50:11Z

Regarding the changes in setup.py: after all the PRs related to removing weights from gRPC messages on xain-fl, xain-sdk and xain-proto are merged, the setup.py on all should actually be updated to point to development branch, correct?

rsaffi · 2020-02-20T08:53:13Z

Regarding the changes in setup.py: after all the PRs related to removing weights from gRPC messages on xain-fl, xain-sdk and xain-proto are merged, the setup.py on all should actually be updated to point to development branch, correct?

Ah, I just saw your message on Slack already covering this. 🥇

Follow-up of #298

* PB-159: update xain-{proto,sdk} dependencies to the right branch Follow-up of #298 * PB-159: fix broken tests This test broke due to a change in xain-sdk. Ref: https://github.com/xainag/xain-sdk/pull/91/

* PB-159: remove weights from gRPC messages References: https://xainag.atlassian.net/browse/PB-159 Needs to be merged along with: - https://github.com/xainag/xain-proto/pull/25 - https://github.com/xainag/xain-sdk/pull/88 - #298 Summary: Remove the weights from the gRPC messages. From now on, weights will be exchanged via s3 buckets. The sequence diagram below illustrate this new behavior. At the beginning of a round (1) the selected participants send a `StartTrainingRound` request, and the coordinator response with the same `StartTrainingRoundResponse` that does not contain the global weights anymore. Instead, the participant fetches these weights from the store (2). S3 buckets are key-value stores, and the key for global weights is the round number. Then, the participant trains. Once done, it uploads its local weights to the S3 bucket (3). The key is `<round_number>/<participant_id>`. Finally (4), the participant sends it's `EndTrainingRequest`. Before answering, the coordinator retrieves the local weights the participant has uploaded. _**Important note**: At the moment, the participants don't know their ID, because the coordinator does not send it to them. Thus, they currently generate a random ID when they start, and send it to the coordinator so that it can retrieve the participant's weights. This is why the `EndTrainingRoundRequest` currently has a `participant_id` field._ ``` P C Store 1. | StartTrainingRoundRequest | | | -----------------------------> | | | StartTrainingRoundResponse | | | <----------------------------- | | | | | | Get global weights (key="round/global") | 2. | ------------------------------------------------------> | | Global weights | | <------------------------------------------------------ | | | | | [train...] | | | | | 3. | Set local weights (key="round/participant") | | ------------------------------------------------------> | | Ok | | <------------------------------------------------------ | | | | 4. | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | ``` At the end of the round, the coordinator writes the weights to the s3 bucket, using the next upcoming round number as key (see the sequence diagram below). ``` P C Store | EndTrainingRoundRequest | | | -----------------------------> | Get local weights (key="round/participant") | | ---------------------> | | | Local weights | | EndTrainingRoundResponse | <--------------------> | | <----------------------------- | | | | | | | Set global weights (key="round+1/participant") | | ---------------------> | | | Ok | | | <--------------------> | ``` Implementation notes: - Initially, we thought we would be using different buckets for the local and global weights. But for now, we use the same bucket for local and global weights for now - We currently store the global weights under different keys. It turns out that this brings un-necessary complexity so we'll probably simplify this in the future - For now, the coordinator doesn't send any storage information to the participants. Thus, the participants need to be configured with the storage information. In the future, the `StartTrainingRoundResponse` could contain the endpoint url, bucket name, etc.

Follow-up of #298

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from 218ecc2 to 4f17e1f Compare February 14, 2020 14:53

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from 4f17e1f to 14304a4 Compare February 14, 2020 15:14

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from 752a2f7 to 573dc12 Compare February 17, 2020 10:19

atymoshchuk reviewed Feb 17, 2020

View reviewed changes

xain_fl/coordinator/coordinator.py Outdated Show resolved Hide resolved

atymoshchuk reviewed Feb 17, 2020

View reviewed changes

xain_fl/coordinator/coordinator.py Show resolved Hide resolved

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from 7dabc27 to a114952 Compare February 17, 2020 13:45

little-dude requested review from finiteprods, janpetschexain and Robert-Steiner February 17, 2020 13:46

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from a114952 to fddbf56 Compare February 17, 2020 13:48

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from fddbf56 to 1770099 Compare February 18, 2020 08:53

atymoshchuk previously approved these changes Feb 18, 2020

View reviewed changes

janpetschexain reviewed Feb 18, 2020

View reviewed changes

tests/store.py Outdated Show resolved Hide resolved

janpetschexain reviewed Feb 18, 2020

View reviewed changes

xain_fl/coordinator/coordinator.py Show resolved Hide resolved

little-dude dismissed atymoshchuk’s stale review via f1efdc6 February 18, 2020 10:22

little-dude requested review from janpetschexain and atymoshchuk February 18, 2020 12:37

janpetschexain previously approved these changes Feb 19, 2020

View reviewed changes

finiteprods previously approved these changes Feb 19, 2020

View reviewed changes

little-dude dismissed stale reviews from finiteprods and janpetschexain via 3ec2d98 February 20, 2020 07:37

little-dude and others added 11 commits February 20, 2020 09:16

fix tests after xain-sdk rebase

ca773de

mypy fix

ccf01c4

fixup

6fa9aab

write global weights for the initial round

c0f2e0c

use numpy.testing.assert_array_equal

a675272

Update xain_fl/coordinator/coordinator.py

ccdc1cf

Co-Authored-By: kwok <kwok.cheung@xain.io>

Update xain_fl/coordinator/coordinator.py

2185444

Co-Authored-By: kwok <kwok.cheung@xain.io>

Update tests/conftest.py

160e5a4

Co-Authored-By: kwok <kwok.cheung@xain.io>

Update tests/test_coordinator.py

e4751b5

Co-Authored-By: kwok <kwok.cheung@xain.io>

address review comment

6910f83

readd tests

bb61423

little-dude force-pushed the PB-159-use-s3-for-transfering-weights branch from 952a0ee to bb61423 Compare February 20, 2020 08:16

little-dude requested a review from finiteprods February 20, 2020 08:18

finiteprods approved these changes Feb 20, 2020

View reviewed changes

little-dude merged commit 05c150b into development Feb 20, 2020

little-dude deleted the PB-159-use-s3-for-transfering-weights branch February 20, 2020 08:51

little-dude added a commit that referenced this pull request Feb 20, 2020

PB-159: update xain-{proto,sdk} dependencies to the right branch

e8d7a4e

Follow-up of #298

little-dude mentioned this pull request Feb 20, 2020

PB-159: update xain-{proto,sdk} dependencies to the right branch #301

Merged

10 tasks

little-dude added a commit that referenced this pull request Feb 25, 2020

PB-159: update xain-{proto,sdk} dependencies to the right branch

23e2f7b

Follow-up of #298

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PB-159: remove weights from gRPC messages #298

PB-159: remove weights from gRPC messages #298

little-dude commented Feb 14, 2020 •

edited by janpetschexain

Loading

atymoshchuk commented Feb 17, 2020

little-dude commented Feb 17, 2020

finiteprods left a comment

little-dude commented Feb 20, 2020

finiteprods left a comment

rsaffi commented Feb 20, 2020

rsaffi commented Feb 20, 2020

PB-159: remove weights from gRPC messages #298

PB-159: remove weights from gRPC messages #298

Conversation

little-dude commented Feb 14, 2020 • edited by janpetschexain Loading

References:

Summary:

Reviewer checklist

atymoshchuk commented Feb 17, 2020

little-dude commented Feb 17, 2020

finiteprods left a comment

Choose a reason for hiding this comment

little-dude commented Feb 20, 2020

finiteprods left a comment

Choose a reason for hiding this comment

rsaffi commented Feb 20, 2020

rsaffi commented Feb 20, 2020

little-dude commented Feb 14, 2020 •

edited by janpetschexain

Loading