ui: encryption stats on stores report #26890

mberhault · 2018-06-21T12:47:53Z

This adds basic file stats to the stores report page.
Also improves the styling:

show decoded key info protobuf fields rather than raw proto (eg:
creation date rather than unix timestamp)
table styling moved to core style file
full-width cells to head different sections

Other changes:

use selectors for memoization
use loading component

Release note (admin ui change): add encryption statistics on stores report page

cockroach-teamcity · 2018-06-21T12:48:02Z

This change is

mberhault · 2018-06-22T11:41:06Z

screenshot of the report page styling with two stores (one with --enterprise-encryption, one without):

I'm not crazy about the full-span header column, but it's a clearer way of denoting a separate section than alternating background colors.

mberhault · 2018-06-22T11:47:24Z

Note: the first two commits are #26802 and should be reviewed there. This is only the UI changes.

mberhault · 2018-06-22T11:54:20Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

-  render(): React.ReactElement<any> {
+  renderKey(isStoreKey: boolean, key: protos.cockroach.ccl.storageccl.engineccl.enginepbccl.KeyInfo$Properties) {
+    // Get the enum name from its value (eg: "AES128_CTR" for 1).
+    const encryptionType = protos.cockroach.ccl.storageccl.engineccl.enginepbccl.EncryptionType[key.encryption_type];


@vilterp, @BramGruneir: FYI since we spent so much time looking for it: this works too to get the enum's string value. Good thing too because using __proto__ makes ui-lint fail.

Huh, not sure how we missed this. Glad you found it; __proto__ kind of sketchy (also glad it made the linter fail).

what were you guys trying to do with __proto__???

bdarnell · 2018-06-26T15:38:52Z

Review status: complete! 0 of 0 LGTMs obtained (and 1 stale)

Comments from Reviewable

vilterp

This is certainly an improvement over what's currently in master, but could use some major design attention (cc @josueeee), e.g. folding all this info into the node detail page or something and getting it into a more standard table.

Code-wise it seems fine; couple of minor comments and lint errors.

vilterp · 2018-06-26T23:01:11Z

pkg/ui/styl/pages/reports.styl

+        text-align center
+        color white
+        font-weight 900
+


@BramGruneir is there a reason that all the debug reports have their styles in here, whereas top-level pages have their own style files?

vilterp · 2018-06-26T23:09:13Z

pkg/ui/src/views/reports/containers/stores/index.tsx

    );
  }

-  renderStore(store: protos.cockroach.server.serverpb.StoreDetails$Properties, key: number) {


would be good to use the Loading component in this file. See jobs/index.tsx for an example.

BramGruneir · 2018-06-27T17:31:20Z

pkg/ui/styl/pages/reports.styl, line 162 at r3 (raw file):

Previously, vilterp (Pete Vilter) wrote…

@BramGruneir is there a reason that all the debug reports have their styles in here, whereas top-level pages have their own style files?

Originally, there was a plan for styles for subsections, like reports, to be in their own file. And as the styles started to diverge more from the base style, it made sense to keep it separate.

Comments from Reviewable

couchand · 2018-06-27T18:24:50Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

 import { EncryptionStatusProps } from "oss/src/views/reports/containers/stores/encryption";
+import { Bytes } from "src/util/format";
+
+const dateFormat = "Y-MM-DD HH:mm:ss Z";


Suggest omitting the time zone here.

Also maybe leverage the helpers in src/views/reports/containers/range/print (which could probably be moved to src/util)

Removed time zone.
I doesn't seem range/print handles seconds since epoch, just the proto Timestamp type.

couchand · 2018-06-27T18:26:11Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

  }

-  render(): React.ReactElement<any> {
+  renderKey(isStoreKey: boolean, key: protos.cockroach.ccl.storageccl.engineccl.enginepbccl.KeyInfo$Properties) {


please no mystery boolean parameters.

at a first glance the two cases seem to share almost nothing. Looking closer, they share an awful lot that's just been copy-pasted. please clean this up

Split into separate functions.

couchand · 2018-06-27T18:26:44Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

-  render(): React.ReactElement<any> {
+  renderKey(isStoreKey: boolean, key: protos.cockroach.ccl.storageccl.engineccl.enginepbccl.KeyInfo$Properties) {
+    // Get the enum name from its value (eg: "AES128_CTR" for 1).
+    const encryptionType = protos.cockroach.ccl.storageccl.engineccl.enginepbccl.EncryptionType[key.encryption_type];


what were you guys trying to do with __proto__???

couchand · 2018-06-27T18:27:33Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+  }
+
+  renderFileStats(stats: protos.cockroach.server.serverpb.StoreDetails$Properties) {
+    if (stats.total_files.eq(0) && stats.total_bytes.eq(0)) {


these and every reference to Longs in protobufs needs to be guarded with FixLong

couchand · 2018-06-27T18:28:15Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+
+    let percentFiles = 100;
+    if (stats.active_key_files !== stats.total_files) {
+      percentFiles = Long.fromInt(100).mul(stats.active_key_files).toNumber() / stats.total_files.toNumber();


why do some arithmetic in one data type and the rest of the arithmetic in a different data type?

You mean do the multiplication using Long and the division using floats? I need longs for multiplications for accuracy, but I need floats for division otherwise I get 33.00% instead of 33.33%

couchand · 2018-06-27T18:30:13Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+      percentFiles = Long.fromInt(100).mul(stats.active_key_files).toNumber() / stats.total_files.toNumber();
+    }
+    let fileDetails = percentFiles.toFixed(2) + "%";
+    fileDetails += " (" + stats.active_key_files + "/" + stats.total_files + ")";


recommend splitting up the numerical pieces from the formatting pieces so you can reasonably test the math and reasonably see what's going on with the formatting

Added calculatePercentage helper

couchand · 2018-06-27T18:32:37Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+        this.renderSimpleRow("Algorithm", encryptionType),
+        this.renderSimpleRow("Key ID", key.key_id),
+        this.renderSimpleRow("Created", createdAt),
+        this.renderSimpleRow("Source", key.source),


throwing all these details in <pre> may look nice to your l33+ h4xx0r eyes but maybe we want to do something else here?

Removed. That was left over from dumping the json representation of the proto, I forgot to drop it when properly formatting the fields.

couchand · 2018-06-27T18:33:09Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+
+    let decodedStatus;

+    // Attempt to decode protobuf.


please move this out of the render so it can be independently tested and memoized

Moved to helper function.

couchand · 2018-06-27T18:34:19Z

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx

+      this.renderKey(true, decodedStatus.active_store_key),
+      this.renderKey(false, decodedStatus.active_data_key),
+      this.renderFileStats(store),
+    ];


do these rows ever get put into a table? edit: oh i see now that they do elsewhere. this is a really really weird way to split up these components, with this one not returning legal markup. i'm kind of surprised it doesn't run into lint/tsc errors or react warnings...

I'm not sure what you mean. Returning arrays of elements? We seem to do this in quite a few places.

couchand · 2018-06-27T18:36:52Z

pkg/ui/src/views/reports/containers/stores/index.tsx

        {
-          _.map(stores.stores, (store, key) => (
-            this.renderStore(store, key)
+          _.map(_.sortBy(stores.stores, (store) => store.store_id), (store) => (


better to move the sort into the selector so we're not redoing it needlessly

I don't actually know what this means.

couchand · 2018-06-28T15:29:34Z

Reviewed 3 of 4 files at r6, 1 of 1 files at r7.
Review status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 61 at r3 (raw file):

Previously, mberhault (marc) wrote…

Sure it does. They have the same type and value.

Unfortunately that's not how it works in JavaScript. This checks that they are the same object. Since they're deserialized from a proto I think they won't ever be.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 62 at r3 (raw file):

Previously, mberhault (marc) wrote…

You mean do the multiplication using Long and the division using floats? I need longs for multiplications for accuracy, but I need floats for division otherwise I get 33.00% instead of 33.33%

I agree that if you want the percentage value to not be truncated you need to use a float type, but I don't think I agree that you need the multiplication by 100 to be done with longs "for accuracy"...

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 102 at r3 (raw file):

Previously, mberhault (marc) wrote…

I'm not sure what you mean. Returning arrays of elements? We seem to do this in quite a few places.

We frequently return arrays from internal methods of a component, but I don't think we're returning arrays from the main render method of a component anywhere. Can you clarify the breakdown of components here? Are these rows going to get rendered into multiple different types of tables or something?

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 35 at r7 (raw file):

    // Get the enum name from its value (eg: "AES128_CTR" for 1).
    const encryptionType = protos.cockroach.ccl.storageccl.engineccl.enginepbccl.EncryptionType[key.encryption_type];
    const createdAt = moment.unix(key.creation_time.toNumber()).utc().format(dateFormat);

FixLong

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 97 at r7 (raw file):

      decodedStatus = protos.cockroach.ccl.storageccl.engineccl.enginepbccl.EncryptionStatus.decode(data);
    } catch (e) {
      console.log("Error decoding protobuf: ", e);

Do we want to report this error to the user at all?

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, mberhault (marc) wrote…

I don't actually know what this means.

We don't want to do any unnecessary work in the render cycle, because the philosophy of React is to make render super lightweight. So if we need to do something heavy like sorting, we should at least make sure it's memoized so we don't keep sorting the same array over and over again.

Down below in mapStateToProps you provide selectors to extract the important pieces of the AdminUIState into your components props. In this case the selectors are simple property accesses, but in more complicated cases we'll use the library reselect which provides a simple interface to memoize selectors. Take a look at the mapStateToProps of other components, and see how they use createSelector to compose & memoize selectors.

Comments from Reviewable

mberhault

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 33 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

what were you guys trying to do with __proto__???

We were looking for the enum value -> enum field name mapping and got slightly side-tracked.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 61 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

Unfortunately that's not how it works in JavaScript. This checks that they are the same object. Since they're deserialized from a proto I think they won't ever be.

True. I'm comparing Long now.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 62 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

I agree that if you want the percentage value to not be truncated you need to use a float type, but I don't think I agree that you need the multiplication by 100 to be done with longs "for accuracy"...

Moved all this to calculatePercentage. It technically does long multiplication followed by float division, but I have to convert at some point so might as well do it there.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 102 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

We frequently return arrays from internal methods of a component, but I don't think we're returning arrays from the main render method of a component anywhere. Can you clarify the breakdown of components here? Are these rows going to get rendered into multiple different types of tables or something?

It was ultimately called from the OSS stores report and inserted directly into the table. Changed it to not have a render method, so it's more of a helper.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 35 at r7 (raw file):

Previously, couchand (Andrew Couch) wrote…

FixLong

Done.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 97 at r7 (raw file):

Previously, couchand (Andrew Couch) wrote…

Do we want to report this error to the user at all?

It'd be nice to report the issue somehow. I don't particularly want to dump it into the report itself.

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

We don't want to do any unnecessary work in the render cycle, because the philosophy of React is to make render super lightweight. So if we need to do something heavy like sorting, we should at least make sure it's memoized so we don't keep sorting the same array over and over again.

Down below in mapStateToProps you provide selectors to extract the important pieces of the AdminUIState into your components props. In this case the selectors are simple property accesses, but in more complicated cases we'll use the library reselect which provides a simple interface to memoize selectors. Take a look at the mapStateToProps of other components, and see how they use createSelector to compose & memoize selectors.

Yeah, none of this is clear or standardized within the code base. I'm also not sure it really matter for a list of stores.

couchand

I think this is close, but there are still some important questions that we should figure out. Let me know if you want to chat about any of the comments.

Reviewed 3 of 3 files at r9.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 62 at r3 (raw file):

Previously, mberhault (marc) wrote…

Moved all this to calculatePercentage. It technically does long multiplication followed by float division, but I have to convert at some point so might as well do it there.

👍

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 102 at r3 (raw file):

Previously, mberhault (marc) wrote…

It was ultimately called from the OSS stores report and inserted directly into the table. Changed it to not have a render method, so it's more of a helper.

Ok, that makes sense. But you probably want to go all the way and not have it be a React component at all now, right? As it is, it's a weird Frankenstein that says it's a React component, but it doesn't have a render method and it's not used as a component.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 97 at r7 (raw file):

Previously, mberhault (marc) wrote…

It'd be nice to report the issue somehow. I don't particularly want to dump it into the report itself.

Agreed, it probably makes sense to display it above the table in an error message.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 61 at r9 (raw file):

  calculatePercentage(active: Long, total: Long): number {
    if (active === total) {

Still broken here, needs to be .eq

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 64 at r9 (raw file):

      return 100;
    }
    return Long.fromInt(100).mul(active).toNumber() / total.toNumber();

i'd still prefer 100 * (active.toNumber() / total.toNumber()) (or if you're worried about overflow, Long.fromInt(10000).mul(active).div(Long.fromInt(100).mul(total)).toNumber() / 100) but i'm not going to push it too hard, this is fine as-is.

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, mberhault (marc) wrote…

Yeah, none of this is clear or standardized within the code base. I'm also not sure it really matter for a list of stores.

I can understand how it looks like that. We haven't had a chance to go back and clean up every page, but if you look at new pages you will see that we are usually quite vigilant about this. It's really important not to prematurely pessimize React render cycles, because you can quickly get crappy performance through death by a thousand cuts.

mberhault

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 102 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

Ok, that makes sense. But you probably want to go all the way and not have it be a React component at all now, right? As it is, it's a weird Frankenstein that says it's a React component, but it doesn't have a render method and it's not used as a component.

Done. Made it a plain object, though the renderX methods still return a ReactElement.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 61 at r9 (raw file):

Previously, couchand (Andrew Couch) wrote…

Still broken here, needs to be .eq

Done.

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

I can understand how it looks like that. We haven't had a chance to go back and clean up every page, but if you look at new pages you will see that we are usually quite vigilant about this. It's really important not to prematurely pessimize React render cycles, because you can quickly get crappy performance through death by a thousand cuts.

OK, I've poked at this quite a few times, every time to end up even more confused than before, I've reached the limit of what I can do with copy-pasta and well.. logic. Would someone mind terribly taking it over from here? I think I've addressed all other comments.

couchand

With my changes added this is about ready to go. I think the one outstanding item is error reporting, and then LGTM.

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 102 at r3 (raw file):

Previously, mberhault (marc) wrote…

Done. Made it a plain object, though the renderX methods still return a ReactElement.

Ok, it's a little weird, but I'm not going to push too hard.

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 97 at r7 (raw file):

Previously, couchand (Andrew Couch) wrote…

Agreed, it probably makes sense to display it above the table in an error message.

I think this is the only outstanding comment.

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, mberhault (marc) wrote…

OK, I've poked at this quite a few times, every time to end up even more confused than before, I've reached the limit of what I can do with copy-pasta and well.. logic. Would someone mind terribly taking it over from here? I think I've addressed all other comments.

I've taken care of it in mberhault#2

mberhault · 2018-08-08T19:28:30Z

Thanks @couchand, I've integrated your changes. However, there seems to be a problem with the stores.data field. I poked around for a while but couldn't figure out what was wrong. Since I'm back in the office, could we sit down and take a look at it at some point?

vilterp · 2018-08-08T20:00:58Z

@couchand is out this week and next but I may be able to help.

vilterp

Squash and LGTM

This adds basic file stats to the stores report page. Also improves the styling: - show decoded key info protobuf fields rather than raw proto (eg: creation date rather than unix timestamp) - table styling moved to core style file - full-width cells to head different sections Other changes: - use selectors for memoization - use loading component Release note (admin ui change): add encryption statistics on stores report page

mberhault

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

pkg/ui/ccl/src/views/reports/containers/stores/encryption.tsx, line 97 at r7 (raw file):

Previously, couchand (Andrew Couch) wrote…

I think this is the only outstanding comment.

Done. Error is shown inside the table itself.

pkg/ui/src/views/reports/containers/stores/index.tsx, line 123 at r3 (raw file):

Previously, couchand (Andrew Couch) wrote…

I've taken care of it in mberhault#2

Thanks! Grabbed your PR and fixed a few things with vilterp's help.

Couch on vacation. All comments addressed.

mberhault · 2018-08-09T19:21:30Z

Squashed and fixed commit message. Thank you all for the reviews and the help with this.

mberhault · 2018-08-09T19:21:33Z

bors r+

26890: ui: encryption stats on stores report r=mberhault a=mberhault This adds basic file stats to the stores report page. Also improves the styling: - show decoded key info protobuf fields rather than raw proto (eg: creation date rather than unix timestamp) - table styling moved to core style file - full-width cells to head different sections Other changes: - use selectors for memoization - use loading component Release note (admin ui change): add encryption statistics on stores report page Co-authored-by: marc <marc@cockroachlabs.com>

craig · 2018-08-09T19:35:24Z

Build succeeded

GitHub CI (Cockroach)

mberhault requested review from a team June 21, 2018 12:47

mberhault mentioned this pull request Jun 21, 2018

libroach: add basic file encryption stats. #26802

Merged

mberhault force-pushed the marc/file_stats_on_stores_report branch 4 times, most recently from 858b728 to c546920 Compare June 22, 2018 11:36

mberhault force-pushed the marc/file_stats_on_stores_report branch from c546920 to 161c454 Compare June 22, 2018 11:45

mberhault requested review from BramGruneir and bdarnell June 22, 2018 11:46

mberhault changed the title ~~WIP: ui: encryption stats on stores report~~ ui: encryption stats on stores report Jun 22, 2018

mberhault commented Jun 22, 2018

View reviewed changes

vilterp reviewed Jun 26, 2018

View reviewed changes

couchand suggested changes Jun 27, 2018

View reviewed changes

mberhault force-pushed the marc/file_stats_on_stores_report branch from 161c454 to 9afa36c Compare June 28, 2018 10:09

mberhault force-pushed the marc/file_stats_on_stores_report branch 5 times, most recently from 873e53c to f4163e2 Compare July 5, 2018 13:24

mberhault commented Jul 5, 2018

View reviewed changes

couchand suggested changes Jul 10, 2018

View reviewed changes

mberhault force-pushed the marc/file_stats_on_stores_report branch from f4163e2 to 07c9ca2 Compare July 24, 2018 12:01

mberhault commented Aug 1, 2018

View reviewed changes

mberhault force-pushed the marc/file_stats_on_stores_report branch from 07c9ca2 to 73d1215 Compare August 1, 2018 09:52

couchand previously requested changes Aug 1, 2018

View reviewed changes

mberhault force-pushed the marc/file_stats_on_stores_report branch from 73d1215 to 393b01e Compare August 6, 2018 11:29

mberhault force-pushed the marc/file_stats_on_stores_report branch from 393b01e to 5fb77a1 Compare August 9, 2018 18:23

vilterp approved these changes Aug 9, 2018

View reviewed changes

mberhault force-pushed the marc/file_stats_on_stores_report branch from 5dace8a to 3145049 Compare August 9, 2018 18:51

mberhault commented Aug 9, 2018

View reviewed changes

mberhault mentioned this pull request Aug 9, 2018

security: encryption at rest #19783

Closed

29 tasks

craig bot merged commit 3145049 into cockroachdb:master Aug 9, 2018

mberhault deleted the marc/file_stats_on_stores_report branch August 9, 2018 19:46

jseldess mentioned this pull request Aug 28, 2018

ui: encryption stats on stores report cockroachdb/docs#3653

Closed

ui: encryption stats on stores report #26890

ui: encryption stats on stores report #26890

Uh oh!

Conversation

mberhault commented Jun 21, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cockroach-teamcity commented Jun 21, 2018

Uh oh!

mberhault commented Jun 22, 2018

Uh oh!

mberhault commented Jun 22, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bdarnell commented Jun 26, 2018

Uh oh!

vilterp left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BramGruneir commented Jun 27, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

couchand commented Jun 28, 2018

Uh oh!

mberhault left a comment

Choose a reason for hiding this comment

Uh oh!

couchand left a comment

Choose a reason for hiding this comment

Uh oh!

mberhault left a comment

Choose a reason for hiding this comment

Uh oh!

mberhault commented Jun 21, 2018 •

edited

Loading

vilterp left a comment •

edited

Loading

vilterp commented Aug 8, 2018 •

edited

Loading