Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-15234

Standardise config and JVM parameters

Agile BoardAttach filesAttach ScreenshotBulk Copy AttachmentsBulk Move AttachmentsVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Normal
    • Resolution: Fixed
    • 4.1-alpha1, 4.1
    • Local/Config
    • None
    • Correctness
    • Normal
    • Normal
    • User Report
    • All
    • None
    • Hide

      CCM patch committed here and retagged.

      DTest patch committed here

      Trunk patch split to 13 patches starts from this one on.

      The existing tests plus new unit tests added. Also, dtests exercise the backward compatibility and test that way that ccm supports the same behavior as Cassandra as regards to configuration parameters loading. 

      Docs in review - CASSANDRA-17246

      Show
      CCM patch committed here  and retagged. DTest patch committed here Trunk patch split to 13 patches starts from this one on. The existing tests plus new unit tests added. Also, dtests exercise the backward compatibility and test that way that ccm supports the same behavior as Cassandra as regards to configuration parameters loading.  Docs in review -  CASSANDRA-17246

    Description

      We have a bunch of inconsistent names and config patterns in the codebase, both from the yams and JVM properties. It would be nice to standardise the naming (such as otc_ vs internode_) as well as the provision of values with units - while maintaining perpetual backwards compatibility with the old parameter names, of course.

      For temporal units, I would propose parsing strings with suffixes of:

      code
      u|micros(econds?)?
      ms|millis(econds?)?
      s(econds?)?
      m(inutes?)?
      h(ours?)?
      d(ays?)?
      mo(nths?)?
      code

      For rate units, I would propose parsing any of the standard B/s, KiB/s, MiB/s, GiB/s, TiB/s.
      Perhaps for avoiding ambiguity we could not accept bauds bs, Mbps or powers of 1000 such as KB/s, given these are regularly used for either their old or new definition e.g. KiB/s, or we could support them and simply log the value in bytes/s.

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            e.dimitrova Ekaterina Dimitrova Assign to me
            benedict Benedict Elliott Smith
            Ekaterina Dimitrova
            Benjamin Lerer, Caleb Rackliffe, David Capwell, Michael Semb Wever
            Votes:
            0 Vote for this issue
            Watchers:
            27 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment