[infinispan-dev] code highlight in github/asciidoc
Github's wiki asciidoc doesn't play nicely with syntax highlighting: displays all the code with the same plain color, instead of highlighting the syntax elements like the IDEs do. E.g. the sample code provided in the wiki asciidoc help: .python.py [source,python] # i just wrote a comment in python print something # and maybe one more renders like: http://screencast.com/t/k6JVQrWQ4 Whilst the markdown equivalent: ```python # i just wrote a comment in python print something # and maybe one more ``` renders as expected: http://screencast.com/t/YLMhs31Jm I think this has been a problem for quite a while now: https://github.com/gollum/gollum/issues/280 Does anyone see any problem with allowing both markdown and asciidoc editors for our wiki? They both have pretty basic syntax and markdown seems to be better integrated (I guess that's why it's also the default editor). Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] code highlight in github/asciidoc
I only suggested AsciiDoc to be consistent with the markup used for our documentation. Having two different markup syntaxes in use for the project could get annoying... but yes, I agree that the lack of syntax highlighting on the wiki can be even more annoying. On 30 October 2013 12:55, Mircea Markus mmar...@redhat.com wrote: Github's wiki asciidoc doesn't play nicely with syntax highlighting: displays all the code with the same plain color, instead of highlighting the syntax elements like the IDEs do. E.g. the sample code provided in the wiki asciidoc help: .python.py [source,python] # i just wrote a comment in python print something # and maybe one more renders like: http://screencast.com/t/k6JVQrWQ4 Whilst the markdown equivalent: ```python # i just wrote a comment in python print something # and maybe one more ``` renders as expected: http://screencast.com/t/YLMhs31Jm I think this has been a problem for quite a while now: https://github.com/gollum/gollum/issues/280 Does anyone see any problem with allowing both markdown and asciidoc editors for our wiki? They both have pretty basic syntax and markdown seems to be better integrated (I guess that's why it's also the default editor). Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] dealing with cluster partitions (design wiki)
Hi, Based on the discussions we had in Farnborough last week, I've set up a wiki design page to describe the work we plan to do for dealing with cluster partitions: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Please review/comment. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] design for cluster events (wiki page)
Hi, I've added a wiki page[1] capturing our discussions around cluster events. Any feedback welcomed! [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] code highlight in github/asciidoc
On Oct 30, 2013, at 4:49 PM, Manik Surtani ma...@infinispan.org wrote: I only suggested AsciiDoc to be consistent with the markup used for our documentation. Having two different markup syntaxes in use for the project could get annoying... but yes, I agree that the lack of syntax highlighting on the wiki can be even more annoying. If it's only that let's just use markup as it is more mature on github. I'll update the docs to state that. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] design for cluster events (wiki page)
Since it seems I can't comment on the wiki itself, I am just replying here. I wonder if the third option 'Primary partition' is desirable. I think availability in some cases would be harmed more than we would like. Lets say you have a 5 node cluster where 3 of the nodes are behind the same router and the remaining 2 are behind a different one. If the router crashes, power loss etc. for the 3 and are no longer addressable you have your 2 partitions (possibly 1 or even 4). When this occurs the other 2 nodes would go into read only mode since they lost the quorum check. But the 3 nodes that are writable can't be accessed any longer and thus no writes can be performed on the cluster. It seems we would still want to allow writes to provide as high of availability as possible. Also if we did have read only, what criteria would cause those nodes to be writeable again? There is no guarantee when the other nodes will ever come back up or if there will ever be additional ones anytime soon. - Will On Wed, Oct 30, 2013 at 2:05 PM, Mircea Markus mmar...@redhat.com wrote: Hi, I've added a wiki page[1] capturing our discussions around cluster events. Any feedback welcomed! [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] design for cluster events (wiki page)
Ups, wrong URL. This is the design for cluster events: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions On Oct 30, 2013, at 7:05 PM, Mircea Markus mmar...@redhat.com wrote: Hi, I've added a wiki page[1] capturing our discussions around cluster events. Any feedback welcomed! [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] design for cluster events (wiki page)
Okay, and now the good URL (3rd try): https://github.com/infinispan/infinispan/wiki/Clustered-listeners On Oct 30, 2013, at 7:31 PM, Mircea Markus mmar...@redhat.com wrote: Ups, wrong URL. This is the design for cluster events: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions On Oct 30, 2013, at 7:05 PM, Mircea Markus mmar...@redhat.com wrote: Hi, I've added a wiki page[1] capturing our discussions around cluster events. Any feedback welcomed! [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] dealing with cluster partitions (design wiki) WAS ( design for cluster events (wiki page))
On Oct 30, 2013, at 7:28 PM, William Burns mudokon...@gmail.com wrote: Since it seems I can't comment on the wiki itself, I am just replying here. I wonder if the third option 'Primary partition' is desirable. I think availability in some cases would be harmed more than we would like. Lets say you have a 5 node cluster where 3 of the nodes are behind the same router and the remaining 2 are behind a different one. If the router crashes, power loss etc. for the 3 and are no longer addressable you have your 2 partitions (possibly 1 or even 4). When this occurs the other 2 nodes would go into read only mode since they lost the quorum check. agreed. But the 3 nodes that are writable can't be accessed any longer and thus no writes can be performed on the cluster. It seems we would still want to allow writes to provide as high of availability as possible. we actually don't take the decision for the user but to plug in his own PartitionHandlingStrategy to make a wiser decision based on their network specifics. The quorum approach written there is just a suggestion, I'll make that clearer. Also if we did have read only, what criteria would cause those nodes to be writeable again? Changing the availability status is possible through JMX, so either manual intervention or some MergeListeners that do that automatically. There is no guarantee when the other nodes will ever come back up or if there will ever be additional ones anytime soon. - Will [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
