[jira] [Commented] (RATIS-92) Move the basic getClassByName methods from RaftProperties to ReflectionUtils
[ https://issues.apache.org/jira/browse/RATIS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060312#comment-16060312 ] Enis Soztutar commented on RATIS-92: Thanks. You can just commit these types of trivial changes without waiting on the reviewer since there is already a +1. At least that is what we do in HBase / Phoenix, and it works well so far. > Move the basic getClassByName methods from RaftProperties to ReflectionUtils > > > Key: RATIS-92 > URL: https://issues.apache.org/jira/browse/RATIS-92 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Minor > Attachments: r92_20170622.patch, r92_20170623.patch > > > getClassByName and getClassByNameOrNull can be changed to static. Then, they > become independent of RaftProperties. It is better to move them to > ReflectionUtils. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (RATIS-92) Move the basic getClassByName methods from RaftProperties to ReflectionUtils
[ https://issues.apache.org/jira/browse/RATIS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059871#comment-16059871 ] Enis Soztutar commented on RATIS-92: +1. small typo here: {code} + * Pares the given string as a {@link SupportedRpcType} {code} > Move the basic getClassByName methods from RaftProperties to ReflectionUtils > > > Key: RATIS-92 > URL: https://issues.apache.org/jira/browse/RATIS-92 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze >Priority: Minor > Attachments: r92_20170622.patch > > > getClassByName and getClassByNameOrNull can be changed to static. Then, they > become independent of RaftProperties. It is better to move them to > ReflectionUtils. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (RATIS-84) A few improvements on the release script
[ https://issues.apache.org/jira/browse/RATIS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991775#comment-15991775 ] Enis Soztutar commented on RATIS-84: +1. > A few improvements on the release script > > > Key: RATIS-84 > URL: https://issues.apache.org/jira/browse/RATIS-84 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r84_20170428.patch > > > - Exclude dependency-reduced-pom.xml. > - Use a better mvn command to get project.name and project.artifactId. > - Show the mvn commands being executed. > - Improve the echo messages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-83) Add a DISCLAIMER file
[ https://issues.apache.org/jira/browse/RATIS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991461#comment-15991461 ] Enis Soztutar commented on RATIS-83: +1. go for it. > Add a DISCLAIMER file > - > > Key: RATIS-83 > URL: https://issues.apache.org/jira/browse/RATIS-83 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r83_20170428.patch > > > We also need a DISCLAIMER file according to > http://incubator.apache.org/guides/branding.html#disclaimers -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-81) Add license header for ratis-replicated-map/README.md
[ https://issues.apache.org/jira/browse/RATIS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987972#comment-15987972 ] Enis Soztutar commented on RATIS-81: +1. > Add license header for ratis-replicated-map/README.md > - > > Key: RATIS-81 > URL: https://issues.apache.org/jira/browse/RATIS-81 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r81_20170427.patch > > > The license header is missing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-80) Add "Apache" to maven project.name
[ https://issues.apache.org/jira/browse/RATIS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987422#comment-15987422 ] Enis Soztutar commented on RATIS-80: +1. > Add "Apache" to maven project.name > -- > > Key: RATIS-80 > URL: https://issues.apache.org/jira/browse/RATIS-80 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r80_20170427.patch > > > Currently, all the project names start with "Ratis". We should change the > name prefix to "Apache Ratis". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RATIS-58) Add rmap.proto
[ https://issues.apache.org/jira/browse/RATIS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved RATIS-58. Resolution: Fixed I've pushed this. Thanks [~jingzhao] for the review. > Add rmap.proto > -- > > Key: RATIS-58 > URL: https://issues.apache.org/jira/browse/RATIS-58 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-58-v1.patch > > > The PB file for the replicated map RPC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RATIS-71) Removed usage of version properties usages for maven-plugins
[ https://issues.apache.org/jira/browse/RATIS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved RATIS-71. Resolution: Fixed I've committed this. Thanks [~khmarbaise] for the patch. > Removed usage of version properties usages for maven-plugins > > > Key: RATIS-71 > URL: https://issues.apache.org/jira/browse/RATIS-71 > Project: Ratis > Issue Type: Improvement >Affects Versions: 0.1.0-alpha >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 0.1.0-alpha > > Attachments: > 0001-RATIS-71-Removed-usage-of-version-properties-usages-.patch > > > Currently there several plugins usages which look like this: > {code:xml} > org.apache.maven.plugins > maven-shade-plugin > ${maven-shade-plugin.version} > {code} > which is superfluous cause the versions are already defined via the > pluginManagement in parent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (RATIS-71) Removed usage of version properties usages for maven-plugins
[ https://issues.apache.org/jira/browse/RATIS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar reassigned RATIS-71: -- Assignee: Karl Heinz Marbaise > Removed usage of version properties usages for maven-plugins > > > Key: RATIS-71 > URL: https://issues.apache.org/jira/browse/RATIS-71 > Project: Ratis > Issue Type: Improvement >Affects Versions: 0.1.0-alpha >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 0.1.0-alpha > > Attachments: > 0001-RATIS-71-Removed-usage-of-version-properties-usages-.patch > > > Currently there several plugins usages which look like this: > {code:xml} > org.apache.maven.plugins > maven-shade-plugin > ${maven-shade-plugin.version} > {code} > which is superfluous cause the versions are already defined via the > pluginManagement in parent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved RATIS-52. Resolution: Fixed > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-52-fix.patch, ratis-52_v1.patch, > ratis-52_v2.patch, ratis-52_v3.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-52: --- Attachment: ratis-52_v3.patch > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-52-fix.patch, ratis-52_v1.patch, > ratis-52_v2.patch, ratis-52_v3.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962532#comment-15962532 ] Enis Soztutar commented on RATIS-52: I've committed v3: {code} [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 06:40 min [INFO] Finished at: 2017-04-10T00:26:46-07:00 [INFO] Final Memory: 34M/411M [INFO] {code} > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-52-fix.patch, ratis-52_v1.patch, ratis-52_v2.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-54) Bump maven.min.version to 3.3.9
[ https://issues.apache.org/jira/browse/RATIS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954243#comment-15954243 ] Enis Soztutar commented on RATIS-54: +1. > Bump maven.min.version to 3.3.9 > --- > > Key: RATIS-54 > URL: https://issues.apache.org/jira/browse/RATIS-54 > Project: Ratis > Issue Type: Task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r54_20170330.patch, r54_20170331.patch > > > [~enis] found that some earlier Maven 3.x version does not work well; see > [this > comment|https://issues.apache.org/jira/browse/RATIS-47?focusedCommentId=15935648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15935648]. > Maven 3.3.9 is the latest stable release, released on 2015-11-14; see > https://maven.apache.org/docs/history.html > It seems reasonable to require Maven 3.3.9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-64) Do not pre-shade artifacts
[ https://issues.apache.org/jira/browse/RATIS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952391#comment-15952391 ] Enis Soztutar commented on RATIS-64: bq. First of all, what is the problem we try to solve? Is it to avoid the imports from org.apache.ratis.shaded packages in our source code? Indeed. It is for keeping the source code shading-free inside Ratis so that we do not fight with the IDE every day. bq. #3 sounds like a good idea. But why we need to kick out ratis-hadoop? I think so, in HBase master code we have both (1) and (3) for example. (3) is implemented in empty-modules hbase-shaded-client and hbase-shaded-server where they each create uber-jars with shaded deps. However, we needed (1), because Hadoop would bring in PB, Guava, etc dependencies which would otherwise cause compilation problems. Again, without removing ratis-hadoop module, we can instead depend on fully shaded Hadoop artifacts so that we can have our versions of PB and Guava in the classpath. However regardless of shading, I feel that ratis-hadoop really does not belong inside Ratis, but it should be maintained inside Hadoop. Maybe once the RPC API is more stable we can consider that refactoring. > Do not pre-shade artifacts > -- > > Key: RATIS-64 > URL: https://issues.apache.org/jira/browse/RATIS-64 > Project: Ratis > Issue Type: Bug >Reporter: Enis Soztutar > > Hugo and I were discussing a case were the shading should happen at the last > step, rather than what we do today. > I think there are 3 possible strategies of shading that one can do: > (1) pre-shade some of your dependencies, so that your other dependencies can > work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. > (2) pre-shade some of your dependencies' transitive dependencies so that you > depend on already-shaded artifacts. This will be like having maven artifacts > of shaded-hadoop so that hadoop itself does not bring in any more dependency. > If hadoop has shaded artifacts, or we do shading of hadoop's dependencies in > another repository, we won't need to pre-shade PB, etc. > (3) post-shade. This means that in the code itself we do not depend on > shaded packages anymore, but do the shading as a different module so that we > publish shaded artifacts. This allows the downstreamers to be able to consume > ratis, while allowing ratis source code to be saner. > Obviously for doing (3), we need to kick out ratis-hadoop module to the > hadoop project. Thinking about it, I think ratis-hadoop does not belong in > Ratis itself anyway. What do you guys think about moving the code over to > Hadoop, and getting rid of the hadoop dependency to end this shading madness? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-64) Do not pre-shade artifacts
[ https://issues.apache.org/jira/browse/RATIS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952385#comment-15952385 ] Enis Soztutar commented on RATIS-64: This is from [~szetszwo], from the mail thread: {quote} I am open to change the shading procedure but I like to understand the motivation. First of all, what is the problem we try to solve? Is it to avoid the imports from org.apache.ratis.shaded packages in our source code? #3 sounds like a good idea. But why we need to kick out ratis-hadoop? I mean why it can't be post-shaded? {quote} > Do not pre-shade artifacts > -- > > Key: RATIS-64 > URL: https://issues.apache.org/jira/browse/RATIS-64 > Project: Ratis > Issue Type: Bug >Reporter: Enis Soztutar > > Hugo and I were discussing a case were the shading should happen at the last > step, rather than what we do today. > I think there are 3 possible strategies of shading that one can do: > (1) pre-shade some of your dependencies, so that your other dependencies can > work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. > (2) pre-shade some of your dependencies' transitive dependencies so that you > depend on already-shaded artifacts. This will be like having maven artifacts > of shaded-hadoop so that hadoop itself does not bring in any more dependency. > If hadoop has shaded artifacts, or we do shading of hadoop's dependencies in > another repository, we won't need to pre-shade PB, etc. > (3) post-shade. This means that in the code itself we do not depend on > shaded packages anymore, but do the shading as a different module so that we > publish shaded artifacts. This allows the downstreamers to be able to consume > ratis, while allowing ratis source code to be saner. > Obviously for doing (3), we need to kick out ratis-hadoop module to the > hadoop project. Thinking about it, I think ratis-hadoop does not belong in > Ratis itself anyway. What do you guys think about moving the code over to > Hadoop, and getting rid of the hadoop dependency to end this shading madness? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-64) Do not pre-shade artifacts
Enis Soztutar created RATIS-64: -- Summary: Do not pre-shade artifacts Key: RATIS-64 URL: https://issues.apache.org/jira/browse/RATIS-64 Project: Ratis Issue Type: Bug Reporter: Enis Soztutar Hugo and I were discussing a case were the shading should happen at the last step, rather than what we do today. I think there are 3 possible strategies of shading that one can do: (1) pre-shade some of your dependencies, so that your other dependencies can work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can work. (2) pre-shade some of your dependencies' transitive dependencies so that you depend on already-shaded artifacts. This will be like having maven artifacts of shaded-hadoop so that hadoop itself does not bring in any more dependency. If hadoop has shaded artifacts, or we do shading of hadoop's dependencies in another repository, we won't need to pre-shade PB, etc. (3) post-shade. This means that in the code itself we do not depend on shaded packages anymore, but do the shading as a different module so that we publish shaded artifacts. This allows the downstreamers to be able to consume ratis, while allowing ratis source code to be saner. Obviously for doing (3), we need to kick out ratis-hadoop module to the hadoop project. Thinking about it, I think ratis-hadoop does not belong in Ratis itself anyway. What do you guys think about moving the code over to Hadoop, and getting rid of the hadoop dependency to end this shading madness? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-56) Update project version to 0.1.0-alpha
[ https://issues.apache.org/jira/browse/RATIS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952379#comment-15952379 ] Enis Soztutar commented on RATIS-56: Forgot to mention, can you also update the version in the new module, ratis-replicated-map. > Update project version to 0.1.0-alpha > - > > Key: RATIS-56 > URL: https://issues.apache.org/jira/browse/RATIS-56 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r56_20170330.patch > > > We may use the following command to update the project version from > 0.1-SNAPSHOT to 0.1.0-alpha. > {code} > find . -name pom.xml | xargs sed -i.old "s/0.1-SNAPSHOT/0.1.0-alpha/g" > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-56) Update project version to 0.1.0-alpha
[ https://issues.apache.org/jira/browse/RATIS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952378#comment-15952378 ] Enis Soztutar commented on RATIS-56: Good to know, but I still think that we should commit this. The reason is that we want the release source tarball to be created from an exact git hash (or tag), so that we can verify the contents are the same as the git tag. If we do not commit this, then we will lose the property that the recursive diff of tarball vs git tag is zero. +1 on the patch. Thanks for driving the release BTW. As an RM, I think you can commit these kind of patches without having to wait for the full round of reviews just to speed things up. On an unrelated note, what can help us for driving frequent releases is to have a script to drive the release process. I think we should do something like this: https://github.com/apache/hbase/blob/master/dev-support/make_rc.sh. > Update project version to 0.1.0-alpha > - > > Key: RATIS-56 > URL: https://issues.apache.org/jira/browse/RATIS-56 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r56_20170330.patch > > > We may use the following command to update the project version from > 0.1-SNAPSHOT to 0.1.0-alpha. > {code} > find . -name pom.xml | xargs sed -i.old "s/0.1-SNAPSHOT/0.1.0-alpha/g" > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951388#comment-15951388 ] Enis Soztutar commented on RATIS-52: bq. I think for this patch we can do the code refactoring work only, i.e., only moving the existing reflection-related methods out of RaftUtils.java Fair enough. Let me commit the fixed version without new code. > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-52-fix.patch, ratis-52_v1.patch, ratis-52_v2.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-61) QuorumSupplier
[ https://issues.apache.org/jira/browse/RATIS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-61: --- Attachment: ratis-61-v1.patch v1 patch. Added a unit test, and some infrastructure for test utilities. > QuorumSupplier > -- > > Key: RATIS-61 > URL: https://issues.apache.org/jira/browse/RATIS-61 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-61-v1.patch > > > Replicated map is like zookeper, where there is a fixed set of known-hosts in > the quorum. No reconfiguration yet. > {code} > QuorumSupplier::List getQuorum() > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-57) Fix pom.xml for mvn release:prepare
[ https://issues.apache.org/jira/browse/RATIS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950031#comment-15950031 ] Enis Soztutar commented on RATIS-57: Thanks. Let's go ahead with the commit. > Fix pom.xml for mvn release:prepare > --- > > Key: RATIS-57 > URL: https://issues.apache.org/jira/browse/RATIS-57 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r57_20170330.patch > > > According to [Prepare your POMs for > release|http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms], > the following command can test the pom. > {code} > mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true > {code} > The JIRA is to fix the unexpected diff between pom.xml and pom.xml.tag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-61) QuorumSupplier
Enis Soztutar created RATIS-61: -- Summary: QuorumSupplier Key: RATIS-61 URL: https://issues.apache.org/jira/browse/RATIS-61 Project: Ratis Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.1.0-alpha Replicated map is like zookeper, where there is a fixed set of known-hosts in the quorum. No reconfiguration yet. {code} QuorumSupplier::List getQuorum() {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-60) Allow direct PB support for Message and SMLogEntry
[ https://issues.apache.org/jira/browse/RATIS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-60: --- Attachment: ratis-60-v0.patch This v0 patch is what I have in the patch from the parent RATIS-40. However, it does not fix the problem, just allows us to have PB-based Message objects. Just attaching for illustrating the problem. > Allow direct PB support for Message and SMLogEntry > -- > > Key: RATIS-60 > URL: https://issues.apache.org/jira/browse/RATIS-60 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-60-v0.patch > > > Right now, for flexibility, both Message and SMLogEntry are ByteStrings. This > allows using custom serialization formats other than PB (or maybe use a > different version of PB). > However, this is very inefficient for the common case where both the messages > and SM Log Entries are themselves PB objects. We unnecessarily serialize > twice. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-60) Allow direct PB support for Message and SMLogEntry
Enis Soztutar created RATIS-60: -- Summary: Allow direct PB support for Message and SMLogEntry Key: RATIS-60 URL: https://issues.apache.org/jira/browse/RATIS-60 Project: Ratis Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar Right now, for flexibility, both Message and SMLogEntry are ByteStrings. This allows using custom serialization formats other than PB (or maybe use a different version of PB). However, this is very inefficient for the common case where both the messages and SM Log Entries are themselves PB objects. We unnecessarily serialize twice. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-59) bin/ script changes for rmap
[ https://issues.apache.org/jira/browse/RATIS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-59: --- Attachment: ratis-59-v1.patch v1 patch. Need RATIS-29 to go in first. > bin/ script changes for rmap > > > Key: RATIS-59 > URL: https://issues.apache.org/jira/browse/RATIS-59 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-59-v1.patch > > > Changes to bin/ scripts for the Rmap server and CLI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-59) bin/ script changes for rmap
Enis Soztutar created RATIS-59: -- Summary: bin/ script changes for rmap Key: RATIS-59 URL: https://issues.apache.org/jira/browse/RATIS-59 Project: Ratis Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.1.0-alpha Changes to bin/ scripts for the Rmap server and CLI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-58) Add rmap.proto
[ https://issues.apache.org/jira/browse/RATIS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-58: --- Attachment: ratis-58-v1.patch > Add rmap.proto > -- > > Key: RATIS-58 > URL: https://issues.apache.org/jira/browse/RATIS-58 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-58-v1.patch > > > The PB file for the replicated map RPC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-58) Add rmap.proto
Enis Soztutar created RATIS-58: -- Summary: Add rmap.proto Key: RATIS-58 URL: https://issues.apache.org/jira/browse/RATIS-58 Project: Ratis Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar The PB file for the replicated map RPC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext
[ https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949753#comment-15949753 ] Enis Soztutar commented on RATIS-8: --- +1 for returning null. > Avoid using Optional for data fields in TransactionContext > -- > > Key: RATIS-8 > URL: https://issues.apache.org/jira/browse/RATIS-8 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Hugo Louro > Attachments: RATIS-8.patch > > > It's usually not recommended to use {{Optional}} as class fields. Let's use > this jira to revisit the {{Optional}} usage in {{TransactionContext}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-52: --- Attachment: ratis-52_v2.patch Thanks Nicholas. Attaching v2 patch which addresses the review. I've kept the PlatformUtils and ReflectionUtils as classes because they indeed have private methods which are better kept as private. > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Attachments: ratis-52_v1.patch, ratis-52_v2.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext
[ https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949584#comment-15949584 ] Enis Soztutar commented on RATIS-8: --- Patch looks good. However, can you also get rid of Optionals from the method return signatures as well. {{TransactionContext}} is a core data structure, which we are expected to be creating tens of thousands per second. Better to get rid of extra object creations. > Avoid using Optional for data fields in TransactionContext > -- > > Key: RATIS-8 > URL: https://issues.apache.org/jira/browse/RATIS-8 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Hugo Louro > Attachments: RATIS-8.patch > > > It's usually not recommended to use {{Optional}} as class fields. Let's use > this jira to revisit the {{Optional}} usage in {{TransactionContext}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-57) Fix pom.xml for mvn release:prepare
[ https://issues.apache.org/jira/browse/RATIS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949535#comment-15949535 ] Enis Soztutar commented on RATIS-57: I don't see any changes other than formatting, am I missing something? > Fix pom.xml for mvn release:prepare > --- > > Key: RATIS-57 > URL: https://issues.apache.org/jira/browse/RATIS-57 > Project: Ratis > Issue Type: Sub-task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r57_20170330.patch > > > According to [Prepare your POMs for > release|http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-poms], > the following command can test the pom. > {code} > mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true > {code} > The JIRA is to fix the unexpected diff between pom.xml and pom.xml.tag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-54) Bump maven.min.version to 3.3.9
[ https://issues.apache.org/jira/browse/RATIS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949501#comment-15949501 ] Enis Soztutar commented on RATIS-54: requiring the latest version is a bit aggressive, but I did not try with an earlier 3.3 release. I know that we have problems with 3.2. Let's go with this for now. Do you mind changing the line in BUILDING.md: {code} Apache Ratis uses Apache Maven for the builds. A 3.2+ version of Maven is required as well as {code} > Bump maven.min.version to 3.3.9 > --- > > Key: RATIS-54 > URL: https://issues.apache.org/jira/browse/RATIS-54 > Project: Ratis > Issue Type: Task >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r54_20170330.patch > > > [~enis] found that some earlier Maven 3.x version does not work well; see > [this > comment|https://issues.apache.org/jira/browse/RATIS-47?focusedCommentId=15935648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15935648]. > Maven 3.3.9 is the latest stable release, released on 2015-11-14; see > https://maven.apache.org/docs/history.html > It seems reasonable to require Maven 3.3.9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-52: --- Attachment: ratis-52_v1.patch v1 patch. Mostly straightforward refactoring. Only change is some addition of more convenience methods in the ReflectionUtils needed by RATIS-40. Other than that no code change. New classes: IOUTils, Iterables, LogUtils, PlatformUtils, Preconditions, ReflectionUtils. RaftUtils is gone. Should we need RAFT (as in protocol-related) utility methods, we can re-add at a later time. Appreciate if Nicolas or Jing can skim over the changes. It is a huge patch, I don't want to keep rebasing. Thanks. > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Attachments: ratis-52_v1.patch > > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (RATIS-52) Refactor RaftUtils into different classes
[ https://issues.apache.org/jira/browse/RATIS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar reassigned RATIS-52: -- Assignee: Enis Soztutar > Refactor RaftUtils into different classes > - > > Key: RATIS-52 > URL: https://issues.apache.org/jira/browse/RATIS-52 > Project: Ratis > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > > Ideally we should not have a generic {{RaftUtils}} class. The code should be > broken up into at least: > {code} > ReflectionUtils -> All reflection, construction, initialization logic > IOUtils -> Add buffer and IO logic > SystemUtils or PlatformUtils -> OS type detection, etc > Preconditions (or something like that) -> assertTrue, etc > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-52) Refactor RaftUtils into different classes
Enis Soztutar created RATIS-52: -- Summary: Refactor RaftUtils into different classes Key: RATIS-52 URL: https://issues.apache.org/jira/browse/RATIS-52 Project: Ratis Issue Type: Improvement Reporter: Enis Soztutar Ideally we should not have a generic {{RaftUtils}} class. The code should be broken up into at least: {code} ReflectionUtils -> All reflection, construction, initialization logic IOUtils -> Add buffer and IO logic SystemUtils or PlatformUtils -> OS type detection, etc Preconditions (or something like that) -> assertTrue, etc {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-8) Avoid using Optional for data fields in TransactionContext
[ https://issues.apache.org/jira/browse/RATIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947623#comment-15947623 ] Enis Soztutar commented on RATIS-8: --- +1 for this. Unlike in other languages, Optional is not a zero-cost abstraction in Java. And without pattern matching, etc, it is not worth it. My Optional usage was a failed experiment. > Avoid using Optional for data fields in TransactionContext > -- > > Key: RATIS-8 > URL: https://issues.apache.org/jira/browse/RATIS-8 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Hugo Louro > > It's usually not recommended to use {{Optional}} as class fields. Let's use > this jira to revisit the {{Optional}} usage in {{TransactionContext}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-51) Add ratis-replicated-map module
[ https://issues.apache.org/jira/browse/RATIS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-51: --- Attachment: ratis-51-v1.patch > Add ratis-replicated-map module > --- > > Key: RATIS-51 > URL: https://issues.apache.org/jira/browse/RATIS-51 > Project: Ratis > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-51-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-40) Replicated Map
[ https://issues.apache.org/jira/browse/RATIS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946442#comment-15946442 ] Enis Soztutar commented on RATIS-40: I am gonna open up subtasks here to get the patches in piece meal. > Replicated Map > -- > > Key: RATIS-40 > URL: https://issues.apache.org/jira/browse/RATIS-40 > Project: Ratis > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1.0-alpha > > Attachments: ratis-40_v1.patch > > > Ratis replicated map is an implementation of a sorted map (think TreeMap) as > a replicated state machine. This is not under examples because it is intended > to be used in production where a simple in-memory map is sufficient to hold > the data. The data is fully cached in memory, but it is still durable since > raft log is used as a replicated log, and data is snapshotted periodically. > The replicated map (RMap) is not only the state machine implementation, but > all of the remaining code, including the client and querying capabilities > which is built on top of the other modules. In that sense, it is dog-fooding > the ratis library to implement an end-to-end solution for a replicated > in-memory data store. > Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the > data is hosted in a known cluster configuration and is not sharded. All the > servers in the cluster participate in a single RAFT ring. > The data model is that users can create independent RMap instances in the > cluster and read / write or scan the data as key value pairs in those > replicated maps. A replicated map named the meta map contains information > about all of the other maps in the cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-51) Add ratis-replicated-map module
Enis Soztutar created RATIS-51: -- Summary: Add ratis-replicated-map module Key: RATIS-51 URL: https://issues.apache.org/jira/browse/RATIS-51 Project: Ratis Issue Type: Sub-task Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.1.0-alpha -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-29) bin/ scripts
[ https://issues.apache.org/jira/browse/RATIS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-29: --- Attachment: ratis-29_v2.patch v2 patch which removes all daemon related scripts. Only the minimum is there right now. {code} bin/ratis bin/ratis-config.sh conf/log4j.properties conf/ratis-env.sh {code} > bin/ scripts > > > Key: RATIS-29 > URL: https://issues.apache.org/jira/browse/RATIS-29 > Project: Ratis > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Attachments: 0001-RATIS-29-bin-scripts.patch, ratis-29_v2.patch > > > We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I > am not very fond of Hadoop's layout, and it is unnecessarily complex for > ratis for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-49) Add a clean profile to remove shaded source
[ https://issues.apache.org/jira/browse/RATIS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946089#comment-15946089 ] Enis Soztutar commented on RATIS-49: Other than what Jing says above, the patch looks good. > Add a clean profile to remove shaded source > --- > > Key: RATIS-49 > URL: https://issues.apache.org/jira/browse/RATIS-49 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r49_20170323b.patch, r49_20170323.patch > > > There is no way to remove the shaded source using mvn. We have to remove > them manually by > - rm -rf ratis-proto-shaded/src/main/java > - rm -rf ratis-hadoop-shaded/src/main/java -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-47) Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded
[ https://issues.apache.org/jira/browse/RATIS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935648#comment-15935648 ] Enis Soztutar commented on RATIS-47: Offline, Nicholas helped me with adding the {{-Dshade-hadoop}} argument. Now it works. Somehow my maven does not pick it up by default. I think we require mvn 3.2+ which is fine. > Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded > - > > Key: RATIS-47 > URL: https://issues.apache.org/jira/browse/RATIS-47 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Fix For: 0.1 > > Attachments: r47_20170317.patch, r47_20170320.patch > > > Even we do not use google guava internally, gRPC still depends on it. > Therefore, we need to shade it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-47) Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded
[ https://issues.apache.org/jira/browse/RATIS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935636#comment-15935636 ] Enis Soztutar commented on RATIS-47: I am getting compilation errors in the recent code base. Is it only me? {code} [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 39.252s [INFO] Finished at: Tue Mar 21 18:44:12 PDT 2017 [INFO] Final Memory: 49M/553M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project ratis-hadoop: Compilation failure: Compilation failure: [ERROR] /Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[38,86] package org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.ProtobufRpcEngineProtos does not exist [ERROR] /Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[39,78] package org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos does not exist [ERROR] /Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[40,78] package org.apache.ratis.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos does not exist [ERROR] /Users/enis/projects/git-repos/ratis/ratis-hadoop/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngineShaded.java:[142,13] cannot find symbol {code} > Shade google guava and combine ratis-netty-shaded with ratis-proto-shaded > - > > Key: RATIS-47 > URL: https://issues.apache.org/jira/browse/RATIS-47 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Fix For: 0.1 > > Attachments: r47_20170317.patch, r47_20170320.patch > > > Even we do not use google guava internally, gRPC still depends on it. > Therefore, we need to shade it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-6) Project logo
[ https://issues.apache.org/jira/browse/RATIS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928875#comment-15928875 ] Enis Soztutar commented on RATIS-6: --- Thanks Will. I like option 6, but it looks too similar to Kafka's? > Project logo > > > Key: RATIS-6 > URL: https://issues.apache.org/jira/browse/RATIS-6 > Project: Ratis > Issue Type: Task >Reporter: Enis Soztutar > Attachments: Ratis.png > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-40) Replicated Map
[ https://issues.apache.org/jira/browse/RATIS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-40: --- Attachment: ratis-40_v1.patch v1 contains bunch of code, and bunch more TODO. But it is a good start I think. Need RATIS-26 and the bin scripts. > Replicated Map > -- > > Key: RATIS-40 > URL: https://issues.apache.org/jira/browse/RATIS-40 > Project: Ratis > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.1 > > Attachments: ratis-40_v1.patch > > > Ratis replicated map is an implementation of a sorted map (think TreeMap) as > a replicated state machine. This is not under examples because it is intended > to be used in production where a simple in-memory map is sufficient to hold > the data. The data is fully cached in memory, but it is still durable since > raft log is used as a replicated log, and data is snapshotted periodically. > The replicated map (RMap) is not only the state machine implementation, but > all of the remaining code, including the client and querying capabilities > which is built on top of the other modules. In that sense, it is dog-fooding > the ratis library to implement an end-to-end solution for a replicated > in-memory data store. > Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the > data is hosted in a known cluster configuration and is not sharded. All the > servers in the cluster participate in a single RAFT ring. > The data model is that users can create independent RMap instances in the > cluster and read / write or scan the data as key value pairs in those > replicated maps. A replicated map named the meta map contains information > about all of the other maps in the cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-40) Replicated Map
Enis Soztutar created RATIS-40: -- Summary: Replicated Map Key: RATIS-40 URL: https://issues.apache.org/jira/browse/RATIS-40 Project: Ratis Issue Type: New Feature Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.1 Ratis replicated map is an implementation of a sorted map (think TreeMap) as a replicated state machine. This is not under examples because it is intended to be used in production where a simple in-memory map is sufficient to hold the data. The data is fully cached in memory, but it is still durable since raft log is used as a replicated log, and data is snapshotted periodically. The replicated map (RMap) is not only the state machine implementation, but all of the remaining code, including the client and querying capabilities which is built on top of the other modules. In that sense, it is dog-fooding the ratis library to implement an end-to-end solution for a replicated in-memory data store. Replicated maps are conceptually similar to ZooKeeper/Etcd/LogCabin where the data is hosted in a known cluster configuration and is not sharded. All the servers in the cluster participate in a single RAFT ring. The data model is that users can create independent RMap instances in the cluster and read / write or scan the data as key value pairs in those replicated maps. A replicated map named the meta map contains information about all of the other maps in the cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-23) Add distribution management to the pom.
[ https://issues.apache.org/jira/browse/RATIS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15898435#comment-15898435 ] Enis Soztutar commented on RATIS-23: Apache parent pom already contains these, no? https://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?view=markup > Add distribution management to the pom. > --- > > Key: RATIS-23 > URL: https://issues.apache.org/jira/browse/RATIS-23 > Project: Ratis > Issue Type: Bug >Reporter: Jitendra Nath Pandey >Assignee: Jitendra Nath Pandey > Attachments: RATIS-23.patch > > > A distributionManagement section should be added to the pom, for releases as > well as snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered
[ https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893161#comment-15893161 ] Enis Soztutar commented on RATIS-33: Offline conversation, it seems that maven did an incompatible change in profile activation, and took away the "OR" functionality without any replacement. Typical. Anyway +1 for the patch. Let's not spend too much time on this. > Protobuf gets compiled only when both activation conditions are triggered > - > > Key: RATIS-33 > URL: https://issues.apache.org/jira/browse/RATIS-33 > Project: Ratis > Issue Type: Bug >Reporter: Jing Zhao >Assignee: Jing Zhao > Attachments: RATIS-33.000.patch, RATIS-33.001.patch, > RATIS-33.002.patch > > > In RATIS-26 we specify the following activation conditions for compiling > protobuf files: > {code} > > > > ${sources.dir} > > > compile-protobuf > > > {code} > This does not work after maven version 3.2.2, due to MNG-4565 that changes > the activation condition relationships from OR to AND. Thus we have to do > both 1) delete ratis-proto-shaded/src/main/java, and 2) include > -Dcompile-protobuf in the command to trigger the protobuf compilation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered
[ https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893063#comment-15893063 ] Enis Soztutar commented on RATIS-33: Does {{mvn clean test}} work? The new profile skipCompileProto does not do anything, maybe I may not be getting it right. > Protobuf gets compiled only when both activation conditions are triggered > - > > Key: RATIS-33 > URL: https://issues.apache.org/jira/browse/RATIS-33 > Project: Ratis > Issue Type: Bug >Reporter: Jing Zhao >Assignee: Jing Zhao > Attachments: RATIS-33.000.patch, RATIS-33.001.patch, > RATIS-33.002.patch > > > In RATIS-26 we specify the following activation conditions for compiling > protobuf files: > {code} > > > > ${sources.dir} > > > compile-protobuf > > > {code} > This does not work after maven version 3.2.2, due to MNG-4565 that changes > the activation condition relationships from OR to AND. Thus we have to do > both 1) delete ratis-proto-shaded/src/main/java, and 2) include > -Dcompile-protobuf in the command to trigger the protobuf compilation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-33) Protobuf gets compiled only when both activation conditions are triggered
[ https://issues.apache.org/jira/browse/RATIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889262#comment-15889262 ] Enis Soztutar commented on RATIS-33: I think the problem I was running into before is something like this: - mvn shading and unpacking the jar contents only happens in the "package" phase. So, if the profile is enabled by default, and you run just {{mvn compile}} or {{mvn test}}, the protoc compilation will happen, but it won't do the shading. That is why I went with the setup where the protoc only runs if the generated directory is not there. Otherwise, we have already generated the files and shaded them by unpacking the jar, so we treat those files as if they are regular source code. {{mvn clean test}} cannot run the shading, because the mvn-shade plugin only operates at a later stage then {{test}}. > Protobuf gets compiled only when both activation conditions are triggered > - > > Key: RATIS-33 > URL: https://issues.apache.org/jira/browse/RATIS-33 > Project: Ratis > Issue Type: Bug >Reporter: Jing Zhao >Assignee: Jing Zhao > Attachments: RATIS-33.000.patch > > > In RATIS-26 we specify the following activation conditions for compiling > protobuf files: > {code} > > > > ${sources.dir} > > > compile-protobuf > > > {code} > This does not work after maven version 3.2.2, due to MNG-4565 that changes > the activation condition relationships from OR to AND. Thus we have to do > both 1) delete ratis-proto-shaded/src/main/java, and 2) include > -Dcompile-protobuf in the command to trigger the protobuf compilation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (RATIS-26) Flatten maven layout and compile shaded atifacts by default
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883920#comment-15883920 ] Enis Soztutar edited comment on RATIS-26 at 2/25/17 1:49 AM: - Thanks [~jingzhao] for the review. bq. "https://ratis.apache.org"; should be "https://incubator.apache.org/projects/ratis.html"; When we have the website (RATIS-5), it will be under https://ratis.apache.org. bq. Similarly for some mailing lists related information we may need to change "ratis.apache.org" to "ratis.incubator.apache.org" I have been using the alias in the lists. I think it works. was (Author: enis): Thanks [~jing] for the review. bq. "https://ratis.apache.org"; should be "https://incubator.apache.org/projects/ratis.html"; When we have the website (RATIS-5), it will be under https://ratis.apache.org. bq. Similarly for some mailing lists related information we may need to change "ratis.apache.org" to "ratis.incubator.apache.org" I have been using the alias in the lists. I think it works. > Flatten maven layout and compile shaded atifacts by default > --- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Fix For: 0.1 > > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, > ratis-26_v2.patch, ratis-26_v3.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (RATIS-26) Flatten maven layout and compile shaded atifacts by default
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved RATIS-26. Resolution: Fixed Fix Version/s: 0.1 Pushed this. > Flatten maven layout and compile shaded atifacts by default > --- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Fix For: 0.1 > > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, > ratis-26_v2.patch, ratis-26_v3.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-26) Flatten maven layout and compile shaded atifacts by default
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883920#comment-15883920 ] Enis Soztutar commented on RATIS-26: Thanks [~jing] for the review. bq. "https://ratis.apache.org"; should be "https://incubator.apache.org/projects/ratis.html"; When we have the website (RATIS-5), it will be under https://ratis.apache.org. bq. Similarly for some mailing lists related information we may need to change "ratis.apache.org" to "ratis.incubator.apache.org" I have been using the alias in the lists. I think it works. > Flatten maven layout and compile shaded atifacts by default > --- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, > ratis-26_v2.patch, ratis-26_v3.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-29) bin/ scripts
[ https://issues.apache.org/jira/browse/RATIS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-29: --- Attachment: 0001-RATIS-29-bin-scripts.patch v1. Includes {{bin/ratis}}, {{conf}} and daemon scripts. You can do bin/ratis classpath for now. Also: {code} bin/ratis org.apache.ratis.util.NativeLibraryChecker {code} > bin/ scripts > > > Key: RATIS-29 > URL: https://issues.apache.org/jira/browse/RATIS-29 > Project: Ratis > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Attachments: 0001-RATIS-29-bin-scripts.patch > > > We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I > am not very fond of Hadoop's layout, and it is unnecessarily complex for > ratis for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-26) Flatten maven layout and compile shaded atifacts by default
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-26: --- Summary: Flatten maven layout and compile shaded atifacts by default (was: Make shaded source compilation as a default action) > Flatten maven layout and compile shaded atifacts by default > --- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, > ratis-26_v2.patch, ratis-26_v3.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-29) bin/ scripts
Enis Soztutar created RATIS-29: -- Summary: bin/ scripts Key: RATIS-29 URL: https://issues.apache.org/jira/browse/RATIS-29 Project: Ratis Issue Type: Bug Reporter: Enis Soztutar Assignee: Enis Soztutar We need {{bin/}} scripts. I will model those from HBase (and not Hadoop). I am not very fond of Hadoop's layout, and it is unnecessarily complex for ratis for now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-26: --- Attachment: ratis-26_v3.patch v3 makes it so that we will only invoke compile-protobuf if the generated sources are missing. Once you do a mvn install, the files will be there, so no need to re-generate and re-shade. {{mvn install -Dcompile-protobuf}} can be used to force-generate those files again. Since the generated code is put under src/main/java, if the generated + shaded files are already there, the compilation and jar packaging just runs as if the code is normally under there (via source checkout). See BUILDING.md. v3 should be ready to check-in. However, if anybody can test it, it would be great. > Make shaded source compilation as a default action > -- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, > ratis-26_v2.patch, ratis-26_v3.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-26: --- Attachment: ratis-26_v2.patch v2 which does some more cleanup, and bringing the poms in line with the ones from HBase/Hadoop. Also added release profile, snapshot repositories, various project-level sections (mailing lists, etc). The tests run with mvn install, but with mvn test, we are still getting ClassNotFoundException due to shaded artifacts not being resolved. In HBase, I think we solve this by checking in the generated files to maven. If I cannot find a way, we can resort to that at worst. > Make shaded source compilation as a default action > -- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch, ratis-26_v2.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-26) Make shaded source compilation as a default action
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879770#comment-15879770 ] Enis Soztutar commented on RATIS-26: Adding to the TODO list: - assemble the list of licenses in assembly for the tarball (see hbase-assembly) All the tests are failing now with NPE or something with the patch. Maybe because of surefire configuration changes? > Make shaded source compilation as a default action > -- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-26) Make shaded source compilation as a default action
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-26: --- Attachment: ratis-26_v1.patch v1 patch (includes Jings patch) as well as some of the above. Let me see whether it needs some more cleanup. {{mvn clean install}} works for me, even if you do {code} rm -rf ratis-proto-shaded/src/main/java/ {code} > Make shaded source compilation as a default action > -- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch, ratis-26_v1.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-26) Make shaded source compilation as a default action
[ https://issues.apache.org/jira/browse/RATIS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879723#comment-15879723 ] Enis Soztutar commented on RATIS-26: Actually I need to make bigger changes in this patch: - Flatten out the maven structure. It should not be like the hadoop's layout with -project and -project-dist, etc. Keep it simple. - Some cleanup in poms - compile + shade by default Some things to do after this patch: - Add missing sections (developers, mailing lists, etc) to pom. - Clean up dependencies - Fix assembly, tarball, etc > Make shaded source compilation as a default action > -- > > Key: RATIS-26 > URL: https://issues.apache.org/jira/browse/RATIS-26 > Project: Ratis > Issue Type: Improvement >Reporter: Jing Zhao >Assignee: Enis Soztutar > Attachments: RATIS-26.000.patch > > > Currently developers need to enter the ratis-proto-shaded directory and run > "mvn package -Dcompile-protobuf" to compile shaded sources. This is not > convenient when updating protobuf definitions. We can make this step a > default step. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-18) A new leader should start serving client requests only after it commits the first leader-placeholder entry
[ https://issues.apache.org/jira/browse/RATIS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872799#comment-15872799 ] Enis Soztutar commented on RATIS-18: bq. And this is how we implement it in the current patch Cool. Sorry, I had not checked the patch in detail. > A new leader should start serving client requests only after it commits the > first leader-placeholder entry > -- > > Key: RATIS-18 > URL: https://issues.apache.org/jira/browse/RATIS-18 > Project: Ratis > Issue Type: Sub-task >Reporter: Jing Zhao >Assignee: Jing Zhao > Attachments: RATIS-18.000.patch, RATIS-18.001.patch > > > When a raft peer becomes the new leader, it can commit entries belonging to > the previous term only along with the entry with the new term. Before that > commit happens, the new leader cannot determine exactly what entries should > be applied to the state machine and the retry cache. The retry cache is > complete only after the leader commits the first leader-placeholder entry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-18) A new leader should start serving client requests only after it commits the first leader-placeholder entry
[ https://issues.apache.org/jira/browse/RATIS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872766#comment-15872766 ] Enis Soztutar commented on RATIS-18: The leader should also gurantee that all of the committed transactions are applied to the state machine before starting to accept reads, no? Different issue? > A new leader should start serving client requests only after it commits the > first leader-placeholder entry > -- > > Key: RATIS-18 > URL: https://issues.apache.org/jira/browse/RATIS-18 > Project: Ratis > Issue Type: Sub-task >Reporter: Jing Zhao >Assignee: Jing Zhao > Attachments: RATIS-18.000.patch > > > When a raft peer becomes the new leader, it can commit entries belonging to > the previous term only along with the entry with the new term. Before that > commit happens, the new leader cannot determine exactly what entries should > be applied to the state machine and the retry cache. The retry cache is > complete only after the leader commits the first leader-placeholder entry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-14) IP-Clearance for Ratis.
[ https://issues.apache.org/jira/browse/RATIS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856648#comment-15856648 ] Enis Soztutar commented on RATIS-14: [~jnp] I think it will help if we include the commit sha in the original repository (https://github.com/hortonworks/ratis). Does this patch correspond to the content of the latest commit (as of Jan 31th 2017) {{d16c5c649311c8af3340c3373593821ba67d467f}}? The link is: https://github.com/hortonworks/ratis/commit/d16c5c649311c8af3340c3373593821ba67d467f I have compared the commits in the incubator repo from the initial import, with sha {{d16c5c649311c8af3340c3373593821ba67d467f}}, and it seems that we are in good shape. {code} git clone http://git.apache.org/incubator-ratis.git git clone https://github.com/hortonworks/ratis.git ratis-legacy cd incubator-ratis git checkout d16c5c649311c8af3340c3373593821ba67d467f diff -r ../ratis-legacy/ . -x .git -x .project -x .settings -x target -x .classpath -x "*.iml" -x .idea {code} Obviously, the sha's in both repos are the same up to {{d16c5c649311c8af3340c3373593821ba67d467f}} by design. > IP-Clearance for Ratis. > --- > > Key: RATIS-14 > URL: https://issues.apache.org/jira/browse/RATIS-14 > Project: Ratis > Issue Type: Bug >Reporter: Jitendra Nath Pandey >Assignee: Jitendra Nath Pandey > Attachments: ratis.patch > > > Ensure ip-clearance documents are provided for Ratis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-13) Add global unique ID for Raft Client
[ https://issues.apache.org/jira/browse/RATIS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852371#comment-15852371 ] Enis Soztutar commented on RATIS-13: +1. I was looking at that recently. Maybe do a ClientId class and use pseudo-random UUIDs. > Add global unique ID for Raft Client > > > Key: RATIS-13 > URL: https://issues.apache.org/jira/browse/RATIS-13 > Project: Ratis > Issue Type: Sub-task >Reporter: Jing Zhao >Assignee: Jing Zhao > > Similar idea as HADOOP-9688. But since we need to support various RPC > engines, the client id is not added in the RPC layer but in the raft protocol > layer. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-6) Project logo
Enis Soztutar created RATIS-6: - Summary: Project logo Key: RATIS-6 URL: https://issues.apache.org/jira/browse/RATIS-6 Project: Ratis Issue Type: Task Reporter: Enis Soztutar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-5) Setup website
Enis Soztutar created RATIS-5: - Summary: Setup website Key: RATIS-5 URL: https://issues.apache.org/jira/browse/RATIS-5 Project: Ratis Issue Type: Task Reporter: Enis Soztutar A project website is needed. Possibly, we can use bootstrap and fork already existing syles. https://phoenix.apache.org/ https://hbase.apache.org/ https://cassandra.apache.org/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-4) Setup jenkins
Enis Soztutar created RATIS-4: - Summary: Setup jenkins Key: RATIS-4 URL: https://issues.apache.org/jira/browse/RATIS-4 Project: Ratis Issue Type: Task Reporter: Enis Soztutar Jenkins unit test builds should be set up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (RATIS-3) Setup hadoopqa builds
[ https://issues.apache.org/jira/browse/RATIS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated RATIS-3: -- Description: A precommit checker would be pretty useful. We can use yetus for this, or do the old way via cloning the hadoopqa script. Our mvn structure is very similar, so should not be a hard issue. > Setup hadoopqa builds > - > > Key: RATIS-3 > URL: https://issues.apache.org/jira/browse/RATIS-3 > Project: Ratis > Issue Type: Task >Reporter: Enis Soztutar > > A precommit checker would be pretty useful. We can use yetus for this, or do > the old way via cloning the hadoopqa script. Our mvn structure is very > similar, so should not be a hard issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-3) Setup hadoopqa builds
Enis Soztutar created RATIS-3: - Summary: Setup hadoopqa builds Key: RATIS-3 URL: https://issues.apache.org/jira/browse/RATIS-3 Project: Ratis Issue Type: Task Reporter: Enis Soztutar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (RATIS-2) Change version to 0.1-SNAPSHOT
[ https://issues.apache.org/jira/browse/RATIS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849062#comment-15849062 ] Enis Soztutar commented on RATIS-2: --- +1. > Change version to 0.1-SNAPSHOT > -- > > Key: RATIS-2 > URL: https://issues.apache.org/jira/browse/RATIS-2 > Project: Ratis > Issue Type: Task >Reporter: Enis Soztutar >Assignee: Jing Zhao > Attachments: RATIS-2.000.patch > > > I think we should change the version to 0.1-SNAPSHOT rather than > 1.0-SNAPSHOT. We can do a couple of 0.x releases before 1.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (RATIS-2) Change version to 0.1-SNAPSHOT
Enis Soztutar created RATIS-2: - Summary: Change version to 0.1-SNAPSHOT Key: RATIS-2 URL: https://issues.apache.org/jira/browse/RATIS-2 Project: Ratis Issue Type: Task Reporter: Enis Soztutar I think we should change the version to 0.1-SNAPSHOT rather than 1.0-SNAPSHOT. We can do a couple of 0.x releases before 1.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)