New metadata API: add MetadataInfo and TargetFile classes #1223

MVrachev · 2020-11-25T16:45:10Z

This pr addresses #1139, but doesn't fix it yet.

I will add a separate pr which will handle Roles and Keys classes.

Description of the changes being introduced by the pull request:
It includes the following changes:

Add a missing root use case in a couple of our tests
Make length and hashes optional in Timestamp as it is in our specification
Add MetaFile class and use it in the Timestamp and Snapshot classes
Add TargetFile class and use it in the Targets class
Rename a few instances of the update method in our classes and use a more verbose name.

Please verify and check that the pull request fulfills the following
requirements:

The code follows the Code Style Guidelines
Tests have been added for the bug fix or new feature
Docs have been added for the bug fix or new feature

lukpueh

Excellent work, @MVrachev and many thanks for taking a stab at this! Don't let the many comments discourage you, they are mostly minor nit picks that should be easy to fix. Let me know when this is ready for another round for review.

tuf/api/metadata.py

MVrachev · 2020-12-01T14:55:55Z

It took me longer than expected, but I updated my pr.
I had to rebase because I dropped the commit in which I renamed update methods.
Additionally, I

added a new commit New API: Make sure we are not changing dict arg
added a new commit Fix documentation indentation as proposed by Lukas.
Addressed all comments made by Lukas.

lukpueh · 2020-12-02T12:05:44Z

@MVrachev and @jku have rightfully pointed out that in my hierarchic from_dict design, which recursively instantiates and assigns nested TUF metadata objects from their json/dict representation, the input data (i.e. the json/dict) is mutated while being parsed, which might be surprising to the caller.

Note that this mutation only occurs in classes that use inheritance, i.e. in Signed and its subclasses Targets/Snapshot/Timestamp. Here is a simplified/abstract demonstration of the issue:

class Parent:
    def __init__(self, some_parent_attr: SomeParentAttr):
        self.some_parent_attr = some_parent_attr

    @classmethod
    def from_dict(cls, data: Dict):
        # Write back into passed 'data' dict so that we can pass it as '**data'
        # to constructor, with parsed value for 'data["some_parent_attr"]',
        # alongside other 'data' values that were parsed in subclasses.
        # FIXME: Mutation of 'data' (passed by reference) might surprise caller
        data["some_parent_attr"] = SomeParentAttr.from_dict(data["some_parent_attr"])
        return cls(**data)

class Child(Parent):
    def __init__(self,
                 some_parent_attr: SomeParentAttr,
                 some_child_attr: SomeChildAttr):
        super().__init__(some_parent_attr)
        self.some_child_attr = some_child_attr

    @classmethod
    def from_dict(cls, data: Dict):
        # Parse and write back into passed 'data' dict so that we can hand it
        # on to the parent class for any additional parsing of 'data' values.
        # FIXME: Mutation of 'data' (passed by reference) might surprise caller
        data["some_child_attr"] = SomeChildAttr.from_dict([data["some_child_attr"]])
        return super().from_dict(data)

@MVrachev proposes to copy (probably rather deepcopy) the input data in the relevant from_dict methods. While this seems like a fair fix, it introduces unnecessary overhead. Here is an alternative solution:

class Parent:
    @classmethod
    def from_dict(cls, data: Dict):
        # Create empty object with default or parametrized constructor with
        # default arguments.
        obj = cls()

        # Parse 'data["some_parent_attr"]' and assign it to the empty object.
        # Any child attributes are parsed and assigned later in the child
        # class.
        obj.some_parent_attr = SomeParentAttr.from_dict(data["some_parent_attr"])
        return obj

class Child(Parent):
    @classmethod
    def from_dict(cls, data: Dict):
        # Call parent parse to get object with parent attributes already
        # assigned and ...
        obj = super().from_dict(data)

        # ... parse and assign any child attributes here.
        obj.some_child_attr = SomeChildAttr.from_dict([data["some_child_attr"]])

        return obj

trishankatdatadog · 2020-12-02T12:16:15Z

Just my 0.02 BTC as an observer:

One thing I regretted adding in my original Metadata API was native JSON decoding/encoding support as class methods. While it works well, it does not not decouple our internal Metadata objects from the data transport format (which need not be JSON).

In my new design, I use an abstract parser which can be overriden to implement different parsers for different data transport formats that nevertheless return the same type of internal Metadata objects we expect.

My new design does not yet account for how to write those internal Metadata objects back into JSON, but I don't believe it would be too difficult while keeping separation of concerns.

Anyway, please carry on, don't let me derail you, I was just making an observation based on something I caused.

lukpueh · 2020-12-02T12:42:07Z

Good point, @trishankatdatadog. This would be a third, more procedural option, for our considerations in secure-systems-lab/securesystemslib#272 (comment). And it indeed completely decouples internal Metadata objects from external transport format.

What I liked about my proposal is that serialization/deserialization logic is organized in small chunks that are encapsulated in the related class.

But I'm really fine either way. Curious to hear what others think.

MVrachev · 2020-12-07T15:52:14Z

@MVrachev and @jku have rightfully pointed out that in my hierarchic from_dict design, which recursively instantiates and assigns nested TUF metadata objects from their json/dict representation, the input data (i.e. the json/dict) is mutated while being parsed, which might be surprising to the caller.

Note that this mutation only occurs in classes that use inheritance, i.e. in Signed and its subclasses Targets/Snapshot/Timestamp. Here is a simplified/abstract demonstration of the issue:

class Parent:
    def __init__(self, some_parent_attr: SomeParentAttr):
        self.some_parent_attr = some_parent_attr

    @classmethod
    def from_dict(cls, data: Dict):
        # Write back into passed 'data' dict so that we can pass it as '**data'
        # to constructor, with parsed value for 'data["some_parent_attr"]',
        # alongside other 'data' values that were parsed in subclasses.
        # FIXME: Mutation of 'data' (passed by reference) might surprise caller
        data["some_parent_attr"] = SomeParentAttr.from_dict(data["some_parent_attr"])
        return cls(**data)

class Child(Parent):
    def __init__(self,
                 some_parent_attr: SomeParentAttr,
                 some_child_attr: SomeChildAttr):
        super().__init__(some_parent_attr)
        self.some_child_attr = some_child_attr

    @classmethod
    def from_dict(cls, data: Dict):
        # Parse and write back into passed 'data' dict so that we can hand it
        # on to the parent class for any additional parsing of 'data' values.
        # FIXME: Mutation of 'data' (passed by reference) might surprise caller
        data["some_child_attr"] = SomeChildAttr.from_dict([data["some_child_attr"]])
        return super().from_dict(data)

@MVrachev proposes to copy (probably rather deepcopy) the input data in the relevant from_dict methods. While this seems like a fair fix, it introduces unnecessary overhead. Here is an alternative solution:

class Parent:
    @classmethod
    def from_dict(cls, data: Dict):
        # Create empty object with default or parametrized constructor with
        # default arguments.
        obj = cls()

        # Parse 'data["some_parent_attr"]' and assign it to the empty object.
        # Any child attributes are parsed and assigned later in the child
        # class.
        obj.some_parent_attr = SomeParentAttr.from_dict(data["some_parent_attr"])
        return obj

class Child(Parent):
    @classmethod
    def from_dict(cls, data: Dict):
        # Call parent parse to get object with parent attributes already
        # assigned and ...
        obj = super().from_dict(data)

        # ... parse and assign any child attributes here.
        obj.some_child_attr = SomeChildAttr.from_dict([data["some_child_attr"]])

        return obj

I agree with your proposal @lukpueh and will change it.
This is a more optimized way to fix that problem.

MVrachev · 2020-12-10T12:30:41Z

I implemented the suggestions from @lukpueh.
I had to give default function arguments for all class arguments assigned in __init__
for Root, Snapshot, Targets, and Timestamp classes.
I chose None as the easiest solution as a default argument, but
we definitely want to add proper validation which will ensure
we are not creating empty or partially populated objects.
I didn't want to create a discussion for sensible defaults
and argument validation here.
There is already an existing issue for that:
#1140

It will be awesome if we can hear the opinions of others.
@joshuagl, @sechkova?

lukpueh

Thanks for the updates, @MVrachev! Speaking of updates, should we add TODO comments to mark the update methods for revision as discussed in #1223 (comment) pp? Otherwise this looks quite good to me. :)

tuf/api/metadata.py

joshuagl

This is looking really neat, great work @MVrachev and thanks for the superb review @lukpueh.

tuf/api/metadata.py

MVrachev · 2020-12-16T13:03:14Z

I addressed all comments made by @joshuagl and rebased to squash some of the commits and prepare this pr for merging.

joshuagl · 2021-01-05T11:10:43Z

Closing to try and re-trigger GHA.

joshuagl · 2021-01-05T11:56:02Z

There are linter failures on the new changes, could you please take a look @MVrachev? Note: it's likely that we need to update pylint configuration for the new coding style.

MVrachev · 2021-01-05T16:07:59Z

I added one commit where I disable inline some of the irrelevant warnings and for warning E1101 I decided to just disable it because it was creating a lot of false-positives.

joshuagl · 2021-01-08T10:54:21Z

tuf/api/metadata.py

+ # cls is most likely a child class of "Signed" and we need to setup
+ # the appropriate fields.
+ obj = cls() # pylint: disable=E1120
+ obj._type = signed_dict['_type'] # pylint: disable=W0212


W0212 is protected-access, we're accessing a protected member outside of the class or a descendent. This makes sense given the pattern of creating an empty object, updating the fields, then returning the populated objet.

AFAIU _type is not actually meant to be "protected" in the Python OOP sense (the naming dates back before our transition to more OOP), but rather is a workaround to not shadow the builtin type name.

Of course, let's add a comment to that effect?

joshuagl · 2021-01-08T11:03:47Z

tuf/api/metadata.py

+ # Warnings about rules E1120 and W0212 are not relevant here because
+ # cls is most likely a child class of "Signed" and we need to setup
+ # the appropriate fields.
+ obj = cls() # pylint: disable=E1120


E1120 is no-value-for-parameter, which is that we're creating an instance of the class without passing values for __init__'s arguments.

joshuagl

Orthogonal to this PR, given the number of linter warnings we're having to disable related to our from_dict pattern, I wonder whether we should document this (and consider other options?) with an ADR. cc @lukpueh

joshuagl · 2021-01-08T11:46:38Z

tuf/api/pylintrc

@@ -1,5 +1,5 @@
 [MESSAGE_CONTROL]
-disable=fixme
+disable=fixme,E1101


E1101 is no-member, a variable has been accessed which the type checker doesn't think is a valid member of that type. That makes sense, we're upcasting to the base Signed type, then accessing members of the subtype.

Rather than disabling this globally, it would probably make more sense to disable it for only the tuf.api.metadata module (by including the #pylint: disable= comment at the top of the module's file).

lukpueh · 2021-01-11T14:24:53Z

Orthogonal to this PR, given the number of linter warnings we're having to disable related to our from_dict pattern, I wonder whether we should document this (and consider other options?) with an ADR. cc @lukpueh

Agreed. I'll put something together.

MVrachev · 2021-01-18T16:38:00Z

Updated the pr.
Added a more detailed comment about E1120 and W0212 and disabled E1101 only for tuf/api/metadata.py.
Also, added a commit with a comment for _type.

Had to rebase in order to return pylintrc back to its original state.

Add a use case for the root class to be tested in test_generic_read and test_read_write_read_compare tests in test_apy.py Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

As per the specification (v1.0.1) length and hashes fields in timestamp metadata are optional. We have implement this in the older API (see theupdateframework#1031) and we should implement it in the new API. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

From the reST/sphinx docs: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#literal-blocks I added new lines and an identation where it was missed. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

Add MetaMetaFileFile class to tuf.api.metadata module. This class is be used for the "meta" field in Timestamp and Snapshot metadata files described the specification. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

Add a new TargetFile class to tuf.api.metadata module make Targets class to use it. This class will contain information about the "targets" field from targets.json Also, update the tests for that change. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

In the Signed.from_dict function we are passing signed - a dictionary. Dictionaries are passed by reference and thus we want to make sure we are not changing the dictionary passed as a function argument. I had to give default function arguments for all class arguments assigned in __init__ for Root, Snapshot, Targets, and Timestamp classes. I chose "None" as the easiest solution as a default argument, but we definitely want to add proper validation which will ensure we are not creating empty or partially populated objects. I didn't want to create a discussion for sensible defaults and argument validation here. There is already existing issue for that: theupdateframework#1140 Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

Warnings E1120 and W0212 are irrelevant in one specific case, but rule E1101 creates a lot of false-positives in tuf/metadata/api. For example, there are 4 false-positives in this file related to "meta" and "targets" fields not existing in "signed_dict" in "from_dict" functions in Timestamp, Snapshot and Targets classes. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

MVrachev · 2021-01-20T18:04:19Z

I updated this pr and had to rebase in order to replace the ** key-value syntax I was using when creating class instances with
directly passing the arguments needed for the __init__ functions.

joshuagl

Thank you for your continued attention on this @MVrachev. I left a few comments, only one of which feels like a blocker – you removed a comment about converting expires so that it can be passed to the constructor as **signed_dict, but you've changed the code away from using that pattern. Should the conversion of expires to a datetime object be removed in favour of it being handled elsewhere?

Nice catch on the sphinx doc strings, can we add some kind of CI/linter check for these in future to prevent them being merged in an incorrect state? This feels issue worthy, rather than something we need to resolve here.

@lukpueh I'd appreciate your review on this, I don't feel quite up to speed on the new metadata API yet.

tuf/api/metadata.py

joshuagl · 2021-01-25T15:16:43Z

tuf/api/metadata.py

+ hashes: A optional dictionary containing hash algorithms and the
+ hashes resulting from applying them over the metadata file.::


I wonder if something like the following might be clearer? Or am I nitpicking?

Suggested change

hashes: A optional dictionary containing hash algorithms and the

hashes resulting from applying them over the metadata file.::

hashes: An optional dictionary mapping hash algorithms to the

hashes resulting from applying them over the metadata file

contents.::

joshuagl · 2021-01-25T15:22:14Z

tuf/api/metadata.py

+
+
+ def __eq__(self, other: 'MetadataInfo') -> bool:
+ """Compare objects by their values instead of by their addresses."""


Nit: by default Python compares objects by their identity, which is like the address but may not be. Can we use the Pythonic term identity here?

Yep, didn't know about that.

joshuagl · 2021-01-25T15:26:39Z

tuf/api/metadata.py

+ hashes: A dictionary containing hash algorithms and the
+ hashes resulted from applying them over the target file::


Similar to the above suggestion, I'd welcome feedback on whether this is clearer or not?

Suggested change

hashes: A dictionary containing hash algorithms and the

hashes resulted from applying them over the target file::

hashes: A dictionary mapping hash algorithms to the

hashes resulting from applying them over the metadata file

contents::

joshuagl · 2021-01-25T15:27:14Z

tuf/api/metadata.py

+
+
+ def __eq__(self, other: 'TargetInfo') -> bool:
+ """Compare objects by their values instead of by their addresses."""


Same comment about identity here.

joshuagl · 2021-01-25T15:33:50Z

tuf/api/metadata.py

@@ -289,22 +291,27 @@ def __init__(
 def from_dict(cls, signed_dict: JsonDict) -> 'Signed':
 """Creates Signed object from its JSON/dict representation. """

+ # Create empty object with default or parametrized constructor with


Suggested change

# Create empty object with default or parametrized constructor with

# Create empty object with default or parameterized constructor with

joshuagl · 2021-01-25T15:35:46Z

tuf/api/metadata.py

 signed_dict['expires'])
- # NOTE: We write the converted 'expires' back into 'signed_dict' above
- # so that we can pass it to the constructor as '**signed_dict' below,
- # along with other fields that belong to Signed subclasses.


Should the removal of this comment indicate we should no longer be doing the conversion of the expires string to a datetime object here?

MVrachev · 2021-02-22T15:33:06Z

On hold, until we merge #1270 and #1279.

joshuagl · 2021-03-17T11:49:14Z

I've converted this PR to draft until it is ready for review. Mostly to save myself from checking the discussion each time to see what the status is.

MVrachev · 2021-03-31T17:41:41Z

I feel like this pr has a lot of discussions and changes that are outdated compared to our current code.

I made a new branch migrating the changes from this pr and found out that: c37bdd2 and the discussion we had with @lukpueh starting from here are no longer relevant to our code, commits
c37bdd2 and b9c70aa are different and
I dropped commit 383e260.

I feel it makes more sense to close this pr and open a new one.

MVrachev · 2021-03-31T18:00:05Z

Replaced by #1329.

MVrachev force-pushed the complex-metadata-classes branch 2 times, most recently from 1f074f8 to 5745088 Compare November 25, 2020 16:58

lukpueh requested changes Nov 26, 2020

View reviewed changes

sechkova reviewed Nov 30, 2020

View reviewed changes

tuf/api/metadata.py Outdated Show resolved Hide resolved

MVrachev force-pushed the complex-metadata-classes branch 5 times, most recently from e517a86 to fd340ad Compare December 1, 2020 14:55

MVrachev mentioned this pull request Dec 1, 2020

New API: Revise "update" methods in tuf/api/metadata.py #1230

Closed

MVrachev force-pushed the complex-metadata-classes branch from fd340ad to bdcdf02 Compare December 1, 2020 19:51

lukpueh mentioned this pull request Dec 3, 2020

Add input validation to simple metadata api #1140

Closed

MVrachev force-pushed the complex-metadata-classes branch from 86aee3f to 2beb35d Compare December 10, 2020 12:29

lukpueh reviewed Dec 10, 2020

View reviewed changes

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Show resolved Hide resolved

MVrachev force-pushed the complex-metadata-classes branch 2 times, most recently from 4e26995 to 194a907 Compare December 10, 2020 15:43

joshuagl reviewed Dec 11, 2020

View reviewed changes

tuf/api/metadata.py Show resolved Hide resolved

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Outdated Show resolved Hide resolved

tuf/api/metadata.py Show resolved Hide resolved

MVrachev mentioned this pull request Dec 14, 2020

New API: Add a constants module #1241

Closed

MVrachev force-pushed the complex-metadata-classes branch from c4f8330 to 56c82de Compare December 14, 2020 15:55

joshuagl closed this Jan 5, 2021

joshuagl reopened this Jan 5, 2021

MVrachev force-pushed the complex-metadata-classes branch from 56c82de to 14ef799 Compare January 5, 2021 16:04

joshuagl reviewed Jan 8, 2021

View reviewed changes

MVrachev force-pushed the complex-metadata-classes branch from 14ef799 to 2e07883 Compare January 18, 2021 16:37

MVrachev changed the title ~~New metadata API: add MetaFile and TargetFile classes~~ New metadata API: add MetadataInfo and TargetFile classes Jan 20, 2021

MVrachev added 9 commits January 20, 2021 20:01

New API: Add root use case in couple of tests

a141580

Add a use case for the root class to be tested in test_generic_read and test_read_write_read_compare tests in test_apy.py Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

NEW API: Fix documentation indentation

b3e98b9

From the reST/sphinx docs: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#literal-blocks I added new lines and an identation where it was missed. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

New API: Document that _type is not protected

cbf4664

Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

New API: Add MetadataInfo class

8cc785c

Add MetaMetaFileFile class to tuf.api.metadata module. This class is be used for the "meta" field in Timestamp and Snapshot metadata files described the specification. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

New API: Add TargetFile class

6259f31

Add a new TargetFile class to tuf.api.metadata module make Targets class to use it. This class will contain information about the "targets" field from targets.json Also, update the tests for that change. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

New API: Add a TODO comments

b9c70aa

Signed-off-by: Martin Vrachev <mvrachev@vmware.com>

MVrachev force-pushed the complex-metadata-classes branch from 2e07883 to 383e260 Compare January 20, 2021 18:02

joshuagl requested a review from lukpueh January 25, 2021 15:37

joshuagl reviewed Jan 25, 2021

View reviewed changes

joshuagl marked this pull request as draft March 17, 2021 11:46

MVrachev closed this Mar 31, 2021

MVrachev mentioned this pull request Mar 31, 2021

New metadata API: add MetaFile and TargetFile classes #1329

Merged

3 tasks

MVrachev deleted the complex-metadata-classes branch March 31, 2021 17:59

lukpueh mentioned this pull request Oct 20, 2021

Metadata API: Consider removing 'update()' methods #1627

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New metadata API: add MetadataInfo and TargetFile classes #1223

New metadata API: add MetadataInfo and TargetFile classes #1223

MVrachev commented Nov 25, 2020 •

edited

Loading

lukpueh left a comment

MVrachev commented Dec 1, 2020

lukpueh commented Dec 2, 2020 •

edited

Loading

trishankatdatadog commented Dec 2, 2020 •

edited

Loading

lukpueh commented Dec 2, 2020

MVrachev commented Dec 7, 2020

MVrachev commented Dec 10, 2020

lukpueh left a comment

joshuagl left a comment

MVrachev commented Dec 16, 2020

joshuagl commented Jan 5, 2021

joshuagl commented Jan 5, 2021 •

edited

Loading

MVrachev commented Jan 5, 2021

joshuagl Jan 8, 2021 •

edited

Loading

lukpueh Jan 11, 2021

joshuagl Jan 14, 2021

joshuagl Jan 8, 2021 •

edited

Loading

joshuagl left a comment •

edited

Loading

joshuagl Jan 8, 2021

lukpueh commented Jan 11, 2021

MVrachev commented Jan 18, 2021

MVrachev commented Jan 20, 2021

joshuagl left a comment

joshuagl Jan 25, 2021

joshuagl Jan 25, 2021

MVrachev Mar 30, 2021

joshuagl Jan 25, 2021

joshuagl Jan 25, 2021

joshuagl Jan 25, 2021

joshuagl Jan 25, 2021

MVrachev commented Feb 22, 2021 •

edited

Loading

joshuagl commented Mar 17, 2021

MVrachev commented Mar 31, 2021

MVrachev commented Mar 31, 2021

		hashes: A optional dictionary containing hash algorithms and the
		hashes resulting from applying them over the metadata file.::



		def __eq__(self, other: 'MetadataInfo') -> bool:
		"""Compare objects by their values instead of by their addresses."""

		hashes: A dictionary containing hash algorithms and the
		hashes resulted from applying them over the target file::



		def __eq__(self, other: 'TargetInfo') -> bool:
		"""Compare objects by their values instead of by their addresses."""

	# Create empty object with default or parametrized constructor with
	# Create empty object with default or parameterized constructor with

New metadata API: add MetadataInfo and TargetFile classes #1223

New metadata API: add MetadataInfo and TargetFile classes #1223

Conversation

MVrachev commented Nov 25, 2020 • edited Loading

lukpueh left a comment

Choose a reason for hiding this comment

MVrachev commented Dec 1, 2020

lukpueh commented Dec 2, 2020 • edited Loading

trishankatdatadog commented Dec 2, 2020 • edited Loading

lukpueh commented Dec 2, 2020

MVrachev commented Dec 7, 2020

MVrachev commented Dec 10, 2020

lukpueh left a comment

Choose a reason for hiding this comment

joshuagl left a comment

Choose a reason for hiding this comment

MVrachev commented Dec 16, 2020

joshuagl commented Jan 5, 2021

joshuagl commented Jan 5, 2021 • edited Loading

MVrachev commented Jan 5, 2021

joshuagl Jan 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshuagl Jan 8, 2021 • edited Loading

Choose a reason for hiding this comment

joshuagl left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lukpueh commented Jan 11, 2021

MVrachev commented Jan 18, 2021

MVrachev commented Jan 20, 2021

joshuagl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MVrachev commented Feb 22, 2021 • edited Loading

joshuagl commented Mar 17, 2021

MVrachev commented Mar 31, 2021

MVrachev commented Mar 31, 2021

MVrachev commented Nov 25, 2020 •

edited

Loading

lukpueh commented Dec 2, 2020 •

edited

Loading

trishankatdatadog commented Dec 2, 2020 •

edited

Loading

joshuagl commented Jan 5, 2021 •

edited

Loading

joshuagl Jan 8, 2021 •

edited

Loading

joshuagl Jan 8, 2021 •

edited

Loading

joshuagl left a comment •

edited

Loading

MVrachev commented Feb 22, 2021 •

edited

Loading