Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chart generator segment memory and new track combinations #668

Merged
merged 12 commits into from
Apr 3, 2019

Conversation

dliappis
Copy link
Contributor

Support new format of track combinations file and include new segment memory visualizations.

dliappis and others added 7 commits March 5, 2019 18:22
and also update the release-charts to cover the default benchmarks too.
--chart-flavor should not be used when generating release charts (and
shouldn't have a default value).
For nightly benchamarks (presented as Time Series) we need to generate
two sets of json files based on the flavor. Thus we need unique titles
for the visualizations and dashboard to separate per flavor.
Chart-generator needs to support generation from both normal tracks as
well as combinations of tracks.

Skip relying on fixed substrings from `--configuration-name` and also
do some general refactorings.
@dliappis dliappis added the enhancement Improves the status quo label Mar 18, 2019
@dliappis dliappis added this to the 1.1.0 milestone Mar 18, 2019
@dliappis dliappis requested a review from ebadyano March 18, 2019 15:56
Copy link
Member

@danielmitterdorfer danielmitterdorfer left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. I left a couple of suggestions.

@@ -51,11 +53,18 @@ def index_label(race_config):
return label


def format_title(environment, track_name, suffix=None):
def format_title(chart_type, environment, track_name, suffix=None, flavor=None):
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I think the suffix should always be the last parameter.

title = "{}-{}".format(environment, track_name)

# as we generate two sets of Time Series/Nightly charts per flavor, the titles needs to be different.
if chart_type == TimeSeriesCharts:
Copy link
Member

Choose a reason for hiding this comment

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

This smells as if it is now in the wrong place if we need to do a type test. IMHO we should implement this now as a method on the respective chart classes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem originally stemed from calling the static method index from within the floating function generate_index_ops:

title = format_title(chart_type, environment, race_configs[0].track, "indexing-throughput", flavor=race_configs[0].flavor)

I've refactored things in 5a3beda

@@ -755,6 +769,9 @@ def index(environment, race_configs, title):
}
}

def __repr__(self):
Copy link
Member

Choose a reason for hiding this comment

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

Why is this needed?

@@ -1187,6 +1319,9 @@ def index(environment, race_configs, title):
}
}

def __repr__(self):
Copy link
Member

Choose a reason for hiding this comment

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

Why is this needed?

structures = []
for flavor, race_configs_per_flavor in race_configs.items():
for race_configs_per_track in race_configs_per_flavor:
logger.debug("Generating charts for race_configs with name:[{}]/flavor:[{}]".format(race_configs_per_track[0].name, flavor))
Copy link
Member

Choose a reason for hiding this comment

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

Our convention is to use plain logger strings for log statements instead of the format API.

idx_race_configs = list(filter(lambda c: "indexing" in c.charts, race_configs))
for race_conf in idx_race_configs:
logger.debug("Gen index visualization for race config with name:[{}] / label:[{}] / flavor: {} / license: {}".format(
Copy link
Member

Choose a reason for hiding this comment

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

Our convention is to use plain logger strings for log statements instead of the format API.



def filter_string(environment, race_config):
def filter_string_time_series(environment, race_config):
Copy link
Member

Choose a reason for hiding this comment

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

This should now be a method on the respective classes if we need to do type tests.

return self.configuration.get("flavor")

@property
def lic(self):
Copy link
Member

Choose a reason for hiding this comment

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

What is lic? License? Is there a reason for the shortcut?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's license, but license is a built-in in Python: https://docs.python.org/3/library/builtins.html

Copy link
Member

Choose a reason for hiding this comment

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

🤦‍♂️ - fair enough but does a property name really clash with a builtin? I mean, it's always used in the context of its enclosing object.

Copy link
Contributor Author

@dliappis dliappis Mar 19, 2019

Choose a reason for hiding this comment

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

It produces noise on the IDE at well and that was an additional motivation behind it. For variables at least it seems to be a strong antipattern to shadow a built-in and @property in Python makes it act as an instance variable so didn't want to do this.

How about eslicense? Naming's not my strongest suit and yet it's hitting me all the time :)

Copy link
Member

Choose a reason for hiding this comment

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

Maybe es_license then?

Copy link
Member

@danielmitterdorfer danielmitterdorfer left a comment

Choose a reason for hiding this comment

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

Thanks, looks great now! LGTM

@danielmitterdorfer danielmitterdorfer added the :Reporting Command line reporting label Mar 19, 2019
@dliappis dliappis merged commit 2ffc948 into elastic:master Apr 3, 2019
@dliappis dliappis deleted the chart-generator-and-flavors branch April 3, 2019 14:47
@ebadyano ebadyano added the :internal Changes for internal, undocumented features: e.g. experimental, release scripts label Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the status quo :internal Changes for internal, undocumented features: e.g. experimental, release scripts :Reporting Command line reporting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants