Skip to content
This repository has been archived by the owner on Oct 23, 2024. It is now read-only.

Make settings in cassandra-yaml.yaml and jvm-options.yaml configurable. #1

Merged
merged 11 commits into from
Oct 20, 2019

Conversation

viivek46
Copy link
Contributor

@viivek46 viivek46 commented Oct 11, 2019

What changes are proposed in this PR?

Resolves DCOS-59493 DCOS-59494

This PR makes setting in both "cassandra-yaml.yml" & "jvm-options.yaml" template configurable, all setting which are configurable in DCOS cassandra for this 2 files are made configurable in this PR.

How were these changes tested?

Manually tested by installing service and checked 'nodetool status'.

@viivek46 viivek46 changed the title Make all settings in "cassandra-yaml.yml" & "jvm-options.yaml" template configurable [DCOS-59493] [DCOS-59494] Make settings in "cassandra-yaml.yml" & "jvm-options.yaml" template configurable Oct 11, 2019
Copy link
Contributor

@mpereira mpereira left a comment

Choose a reason for hiding this comment

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

Thanks @viivek46. It's looking good. I did a first pass at reviewing and left some comments.

operator/templates/cassandra-yaml.yaml Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
operator/templates/jvm-options.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
@mpereira
Copy link
Contributor

mpereira commented Oct 11, 2019

I also noticed that some settings in both cassandra-yaml.yaml and jvm-options.yaml remain unconfigurable.

@mpereira
Copy link
Contributor

Also, please take a look at the style guide for opening PRs. 🙂

@mpereira mpereira changed the title [DCOS-59493] [DCOS-59494] Make settings in "cassandra-yaml.yml" & "jvm-options.yaml" template configurable Make settings in cassandra-yaml.yaml and jvm-options.yaml configurable. Oct 11, 2019
@viivek46
Copy link
Contributor Author

I also noticed that some settings in both cassandra-yaml.yaml and jvm-options.yaml remain unconfigurable.

Yes i refer our existing framework for that, all which were exposed in our existing framework for this templates i have exposed here, but if you think we should expose more, please let me know.

@viivek46
Copy link
Contributor Author

Also, please take a look at the style guide for opening PRs.

OK @mpereira , but is there any specific reason why we are removing jira tickets number, as generally we follow this format.

Copy link

@samvantran samvantran left a comment

Choose a reason for hiding this comment

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

Good stuff @viivek46! I left a couple comments but thanks for making all these customizable.

Also I vote that we should put the JIRA ticket in title. Makes it easier to find the ticket/motivation for the changes.

operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Show resolved Hide resolved
operator/params.yaml Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/params.yaml Outdated Show resolved Hide resolved
operator/templates/cassandra-yaml.yaml Outdated Show resolved Hide resolved
@mpereira
Copy link
Contributor

mpereira commented Oct 14, 2019

@viivek46: Yes i refer our existing framework for that, all which were exposed in our existing framework for this templates i have exposed here, but if you think we should expose more, please let me know.

Yes, let's make all settings configurable.

@mpereira
Copy link
Contributor

mpereira commented Oct 14, 2019

@viivek46: OK @mpereira , but is there any specific reason why we are removing jira tickets number, as generally we follow this format.

Yeah, the JIRA tag in commit messages is useful for us, but here's a couple of reasons I have in mind:

  • this project isn't related to "DC/OS"
  • the kudobuilder/operators repository where this operator will be moved to soon doesn't have a practice of tagging commits with JIRA ticket numbers

cc @samvantran

viivek46 and others added 4 commits October 14, 2019 21:25
@viivek46
Copy link
Contributor Author

@mpereira

I have added many more setting configurable, but there are some still left and the reason i haven't added those is because :

  • Few were conflicting and some were between jvm and cassandra yaml files.
  • Few configs and related still need to decide what to do about it, like : listen_address
    rpc_address
  • also like few i was sure that it wont work with existing setup like authenticator, authorizer. so haven't made it configurable.
  • Also for few I was not sure how to add those.

Copy link

@samvantran samvantran left a comment

Choose a reason for hiding this comment

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

Minor nits but looks good to me!

operator/params.yaml Outdated Show resolved Hide resolved
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
{{ if .Params.SURVIVORRATIO }}

Choose a reason for hiding this comment

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

If these have default values are were not originally commented, do we still need if checks?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@samvantran Reason i did this because i was not sure how blank value will be treated here, so included in conditional block.

@mpereira
Copy link
Contributor

@viivek46: Few were conflicting and some were between jvm and cassandra yaml files

That's a good point. In that case, let's give precedence to the cassandra-yaml.yaml template, and not make them configurable in the jvm-options.yaml. On a managed service like this operator, I don't see a reason why one would need to override a setting via JVM options if it's also available in the configuration file. Could you think of any? cc @samvantran

Copy link
Contributor

@mpereira mpereira 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 progress so far, and for bearing with our feedback @viivek46.

operator/templates/jvm-options.yaml Outdated Show resolved Hide resolved
@mpereira
Copy link
Contributor

I was also wondering if for the JVM options (-XX flags) if it would make sense to prepend something like JVM_OPT_ to the setting names. e.g.: JVM_OPT_MAX_TENURING_THRESHOLD.

That way, Cassandra parameters and JVM options would be more easily distinguished.

What do you think, @viivek46, @samvantran?

@viivek46 viivek46 requested a review from mpereira October 16, 2019 18:10
@viivek46
Copy link
Contributor Author

I was also wondering if for the JVM options (-XX flags) if it would make sense to prepend something like JVM_OPT_ to the setting names. e.g.: JVM_OPT_MAX_TENURING_THRESHOLD.

That way, Cassandra parameters and JVM options would be more easily distinguished.

What do you think, @viivek46, @samvantran?

Yea thats better, i have updated PARAM like that.

@samvantran
Copy link

samvantran commented Oct 16, 2019

On a managed service like this operator, I don't see a reason why one would need to override a setting via JVM options if it's also available in the configuration file. Could you think of any? cc @samvantran

my guess is that different settings were incrementally added over time and we're catching these discrepancies bc we're looking at it as a whole with fresh eyes. I agree with Murilo, when in doubt, go with cassandra.yaml as the place to set a config.

I was also wondering if for the JVM options (-XX flags) if it would make sense to prepend something like JVM_OPT_ to the setting names. e.g.: JVM_OPT_MAX_TENURING_THRESHOLD.

💯

Copy link
Contributor

@mpereira mpereira left a comment

Choose a reason for hiding this comment

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

I've opened a PR with a few fixes and improvements against this PR, please take a look @samvantran and @viivek46 : #2

I think other than the things in the PR above, this PR looks good. The last thing I think we should do is make the authenticator and authorizer configurable. Even though the operator doesn't currently provide any automation for creating users and credentials via cqlsh, it is still possible for users to do it themselves by following the Cassandra docs, so let's make those configurable.

@mpereira
Copy link
Contributor

Thanks for the changes @viivek46. Let's wait for @samvantran to have another look at #2 and then we can get both PRs merged!

@mpereira
Copy link
Contributor

I'll also run some tests that I have in a wip branch to make sure the operator is still working.

* Add units to setting names, improve names, use correct settings.

* Make this look scarier.

* Misc improvements.

* Better name.

* Use fully-scoped actual setting names.

* Leave initial_token unconfigurable for now.
Copy link
Contributor

@mpereira mpereira left a comment

Choose a reason for hiding this comment

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

This PR looks good to me now. I'll approve it, but before merging, please try merging in #3 into your local branch and running the tests, so that we make sure that everything (install/uninstall with no settings) is still working.

Thanks again for your work @viivek46, and your careful reviews @samvantran.

@mpereira
Copy link
Contributor

try merging in #3 into your local branch and running the tests, so that we make sure that everything (install/uninstall with no settings) is still working.

I just did this and the tests passed. 🎉

@viivek46 viivek46 merged commit 05b09e8 into master Oct 20, 2019
@viivek46 viivek46 deleted the configuration-cassandra-yaml branch October 20, 2019 16:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants