Skip to content

schema: enforce cluster name length and invalid chars#667

Merged
mattklein123 merged 6 commits intomasterfrom
max-cluster-name
Apr 5, 2017
Merged

schema: enforce cluster name length and invalid chars#667
mattklein123 merged 6 commits intomasterfrom
max-cluster-name

Conversation

@junr03
Copy link
Copy Markdown
Member

@junr03 junr03 commented Apr 1, 2017

@lyft/network-team

Right now the longest stat prefix and trailing stat that we output for clusters is cluster.<cluster_name>.outlier_detection.ejections_consecutive_5xx, which is 52 characters long. In order to have a bit more room to grow 60 characters might be a good limit to have on cluster name length right now.

In addition we can use regex in the schema to enforce the absence of invalid characters, : for now.

fixes #573

@mattklein123
Copy link
Copy Markdown
Member

tests

@mattklein123
Copy link
Copy Markdown
Member

@kyessenov FYI

try {
create(*loader);
} catch (Json::Exception& e) {
EXPECT_EQ("JSON object doesn't conform to schema.\n Invalid schema: #/properties/name.\n "
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just validate against Json::Exception and do not do precise check on the message. The message can change with the library update, etc. I think it should be sufficient to check that it's not successful creation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, this is a better test. Otherwise a JSON exception could be thrown for any number of reasons. If you don't want to do an exact string match, you could do a find(), or even change the Exception type to be a JsonSchemaException which derives from JsonException.

Also, as an aside, you need to fail in the case where you don't throw an exception. Optimally you would be doing something like EXPECT_THROW(). It would be nice to actually make a variant of EXPECT_THROW() that can check against a message also.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"I disagree, this is a better test." yup, we quickly chatted with Jose on this offline and he was expressing similar concerns, which is a valid point.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was looking for something like that in gtest.

Json::ObjectPtr loader = Json::Factory::LoadFromString(json);
try {
create(*loader);
ADD_FAILURE() << "Json::Exception should take place. It did not.";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a common pattern that we will do again (and should do more). make a macro like EXPECT_THROW(), EXPECT_THROW_WITH_MESSAGE(), put it somewhere common, then use it.

@kyessenov
Copy link
Copy Markdown
Contributor

Does this apply to CDS/RDS supplied clusters?

@mattklein123
Copy link
Copy Markdown
Member

@kyessenov yes

"JSON object doesn't conform to schema.\n Invalid schema: "
"#/properties/name.\n Invalid keyword: maxLength.\n Invalid document "
"key: #/name");
factory_.tls_.shutdownThread();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not required any more


#include "common/http/header_map_impl.h"

using testing::_;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't do "using" in a header file like this. Remove and be explicit below.

Jose Nino added 2 commits April 4, 2017 16:22
@mattklein123 mattklein123 merged commit 9e7ddea into master Apr 5, 2017
@mattklein123 mattklein123 deleted the max-cluster-name branch April 5, 2017 18:56
rshriram pushed a commit to rshriram/envoy that referenced this pull request Oct 30, 2018
nezdolik pushed a commit to nezdolik/envoy that referenced this pull request May 4, 2024
This unbreaks some cases where patching complains about too short
functions to patch.

What happens is we first locate one of CRT-s (like ucrt or msvcrt) and
patch __expand there, redirecting to our implementation. Then "static"
__expand replacement is patched, but it is usually imported from that
same C runtime DLL. And through several jmp redirections we end up at
our own __expand from libc<1>. Patching that (and other cases) is
wrong, but I am unsure how to fix it properly. So we do most simple
workaround. I found that when it not fails is either in debug builds
where empty expand is not too short or when MSVC deduplicates multiple
identical __expand implementations into single function, or when
64-bit patching has to do extra trampoline thingy. And then our
patching code checks if we're trying to replace some function with
itself. So we "just" take advantage of that and get immediate issue
fixed, while punting on more general "duplicate" patching for later.

Update github issue envoyproxy#667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document limits on cluster names and reject cluster names that exceed it

4 participants