From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
No edit summary
Line 34: Line 34:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: jvanek@rehat.com
* Email: jvanek@rehat.com
** #fedora-java
** #fedora-devel
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
Line 127: Line 129:
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
No known project is aiming to be packed with Elasticsource as dependence in close future,  but the grow of packages requesting it can be expected.
No known project is aiming to be packed with Elasticsource as dependence in close future,  but the grow of packages requesting it can be expected.
Currently known third party users who will welcome this packed are NSA (yes, ''that''' NSA) and Searchisko (hidden jboss documentation bounding tool)
Currently known third party users who will welcome this packed are NSA (yes, '''that''' NSA) and Searchisko (hidden jboss documentation bounding tool)
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


Line 136: Line 138:
** Although I'm initiator of this, I hope from help from other people around bug 902086 and people around Searchisko.
** Although I'm initiator of this, I hope from help from other people around bug 902086 and people around Searchisko.
** Considering the status of the build, the only expected failure is in despondences - that we will not be able to agree on versions
** Considering the status of the build, the only expected failure is in despondences - that we will not be able to agree on versions
** Another failure may raise when some capital dependence change owener and he will notbe aware about Elasticsearch boundaries
** Another failure may raise when some capital dependence change owener and he will not be aware about Elasticsearch boundaries
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
Line 142: Line 144:
   <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
   <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release?  Cureently I would say yes
* Blocks release?  no
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? no <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? no <!-- Applicable for Changes that blocks specific product release/Fedora.next -->

Revision as of 13:15, 20 November 2014


Elasticsearch

Summary

Goal of this change is to pack Elasticsearch into main fedora repo.

Owner

  • Name: Jiri Vanek
  • Email: jvanek@rehat.com
    • #fedora-java
    • #fedora-devel
  • Release notes owner:

Current status

Detailed Description

The Elasticsearch is fully-featured self-standing opensource indexing server. Many people and many tools do use it. And many people do wont it in Fedora. Aim of this Change is to make elastic search available by simple yum install elasticsearch, and of course enable it as dependence. To build a custom indexing tool on top of elastic search is more easy then current upstream install and download.

Benefit to Fedora

Users of fedora will be able yum install elasticsearch, will be able to use it as dependence and use it in current project without fighting with monolithic upstream installation.

Scope

  • Proposal owners:
    • pack Elasticsearch - nearly done - see RHBZ#902086
    • make it somehow works
    • verify it works
    • tune list of crucial depnedences
    • enable Elasticsearch as service - something what have to be decided
  • Other developers:
    • This is crucial part of this proposal
    • Elastic search is extremely tuned application, and like it, its dependences must be strictly kept in correct versions
    • Currently known troublemakers:
      • lucene
      • netty3
      • sigar
  • Release engineering:
    • Nothing I'm aware about.
  • Policies and guidelines:
    • Nothing I'm aware about.

Upgrade/compatibility impact

  • when Elasticsearch is updated, all its dependencies must be aligned to exact versions it needs
  • Non of its dependencies can be updated, unless Elasticsearch is known to work on it
  • The list of such restricted despondencies must evolve - currently those three "troublemakers"


How To Test

  • yum install elasticsearch
    • start it/use its service
  • send json request, accept reply

User Experience

Users are able to use packed Elasticsearch after custom run on some port, or as sevice on known port.

Dependencies

No known project is aiming to be packed with Elasticsource as dependence in close future, but the grow of packages requesting it can be expected. Currently known third party users who will welcome this packed are NSA (yes, that NSA) and Searchisko (hidden jboss documentation bounding tool)


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)
    • Although I'm initiator of this, I hope from help from other people around bug 902086 and people around Searchisko.
    • Considering the status of the build, the only expected failure is in despondences - that we will not be able to agree on versions
    • Another failure may raise when some capital dependence change owener and he will not be aware about Elasticsearch boundaries
  • Contingency deadline: Ugh... You tell me...
  • Blocks release? no
  • Blocks product? no

Documentation


Release Notes