Latest revision as of 20:51, 28 August 2015

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

Targeted release: Fedora 22
Last updated: 2014-11-03
Tracker bug: #1181564
Original bug: https://bugzilla.redhat.com/show_bug.cgi?id=902086

Detailed Description

The Elasticsearch is fully-featured self-standing opensource indexing server. Many people and many tools do use it. And many people do want 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
  - compress-lzf
  - guava (currently needed 18, avaiable 17)

Release engineering:
- Nothing I'm aware about.

Policies and guidelines:
- Nothing I'm aware about.
- maybe... fedora is going by way - keep as updated as possible, if it breaks something, that something have to be fixed. This is not best for ES. Maybe ES can et some helping exception?

Upgrade/compatibility impact

original statement - although correct, can be understood to strictly

[1] when Elasticsearch is updated, all its dependencies must be aligned to exact versions it needs
- this can involve adding a number of compact packages for ES in case of unsolvable issues
[2] Non of its dependencies can be updated, unless Elasticsearch is known to work on it
[3] The list of such restricted despondencies must evolve - see currently known "troublemakers" section

Fixed/more detailed statement:

[1] It does not mean to to force libraries to update/downgrade to exact version
- [a] In rawhide, it would be necessary to agree on mayor versions of libraries, that also elasticsearch can be built/run
- [b] in released version, the minor changes should probably not meter, but would be nice to test ES build/runtime against the,
[2] Similarly as [1] it does not mean that libraries should be prevented to update.
- if library is about to be updated, some time should be given to elastic to update. Or better, to let ES upstream to adapt.
- maintaining compact mayor versions of older packages should be perfectly ok by people around ES

again - I do not wont to lock libraries - I wont to try some kind of cooperation

[3] If it will appear that this list of libraries is unmaintainable, then I don't know how to proceed (except dropping ES)
- Still I think this may be tried

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 (Search and content delivery platform behind jboss.org web site).

Contingency Plan 1 - new package

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 dependences - 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
If some mayor depndency problems rise
- create compact packages for them
- if that fails, drop this feature from f22
a lot of was agreed here: http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/fesco.2015-01-07-18.01.log.html I'm not going to rewrite it here, but all in this log should be followed.
Contingency deadline: Ugh... You tell me...
Blocks release? no
Blocks product? no

Contingency Plan 2 - updates

1. try to keep package aligned with fedora
- adapt ES to higher versions, post patches upstream
2. if above fails, ask maintainers of freshly updated, suddenly uncompatible, packages to revert and wait a while
3. if above fails, create compact package
If all above fails - drop package from fedora and wait for software collections

Documentation

https://bugzilla.redhat.com/show_bug.cgi?id=902086 and specfiles linked from here
upstream pages http://www.elasticsearch.com/products/elasticsearch
upstream git https://github.com/elasticsearch/elasticsearch/

Release Notes

@@ Line 56: / Line 56: @@
 CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 -->
-* Tracker bug: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1181564 #1181564]
 * Original bug: https://bugzilla.redhat.com/show_bug.cgi?id=902086
 == Detailed Description ==
 <!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
-The [http://www.elasticsearch.com/products/elasticsearch Elasticsearch] is fully-featured self-standing [https://github.com/elasticsearch/elasticsearch/ opensource] indexing server. Many people and many tools do use it. And many people do wont it in Fedora.
+The [http://www.elasticsearch.com/products/elasticsearch Elasticsearch] is fully-featured self-standing [https://github.com/elasticsearch/elasticsearch/ opensource] indexing server. Many people and many tools do use it. And many people do want 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.
@@ Line 95: / Line 95: @@
 <!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
 ** Nothing I'm aware about.
+** maybe... fedora is going by way - keep as updated as possible, if it  breaks something, that something have to be fixed. This is not best for ES. Maybe ES can et some helping exception?
 == Upgrade/compatibility impact ==
 <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
-* 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"
+'''original statement - although correct, can be understood to strictly'''
+* [1] when Elasticsearch is updated, all its dependencies must be aligned to exact versions it needs
+** this can involve adding a number of compact packages for ES in case of unsolvable issues
+* [2] Non of its dependencies can be updated, unless Elasticsearch is known to work on it
+* [3] The list of such restricted despondencies must evolve - see currently known "troublemakers" section
+'''Fixed/more detailed statement:'''
+* [1] It does not mean to to force libraries to update/downgrade to exact version
+** [a] In rawhide, it would be necessary to agree on mayor versions of libraries, that also elasticsearch can be built/run
+** [b] in released version, the minor changes should probably not meter, but would be nice to test ES build/runtime against the,
+* [2] Similarly as [1] it does not mean that libraries should be prevented to update.
+** if library is about to be updated, some time should be given to elastic to update. Or better, to let  ES upstream to adapt.
+** maintaining compact mayor versions of older packages should be perfectly ok by people around ES
+'''again - I do not wont to lock libraries - I wont to try some kind of cooperation'''
+* [3] If it will appear that this list of libraries is unmaintainable, then I don't know how to proceed (except dropping ES)
+** Still I think this may be tried
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 134: / Line 151: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-== Contingency Plan ==
+== Contingency Plan 1 - new package ==
 <!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 * 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
+** Considering the status of the build, the only expected failure is in dependences - 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
+* If some mayor depndency problems rise
+** create compact packages for them
+** if that fails, drop this feature from f22
+* a lot of was agreed here: http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/fesco.2015-01-07-18.01.log.html I'm not going to rewrite it here, but all in this log should be followed.
 <!-- 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. -->
@@ Line 148: / Line 169: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 * Blocks product? no <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
+== Contingency Plan 2 - updates ==
+* 1. try to keep package aligned with fedora
+** adapt ES to higher versions, post patches upstream
+* 2. if above fails, ask maintainers of freshly updated, suddenly uncompatible, packages to revert and wait a while
+* 3. if above fails, create compact package
+* If all above fails - drop package from fedora and wait for software collections
 == Documentation ==
 <!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
 * https://bugzilla.redhat.com/show_bug.cgi?id=902086 and  specfiles linked from here
-* usptream pages http://www.elasticsearch.com/products/elasticsearch
+* upstream pages http://www.elasticsearch.com/products/elasticsearch
-* usptream git  https://github.com/elasticsearch/elasticsearch/
+* upstream git  https://github.com/elasticsearch/elasticsearch/
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == Release Notes ==
@@ Line 164: / Line 191: @@
 -->
-[[Category:ChangeReadyForWrangler]]
+[[Category:ChangeAcceptedF22]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Search

Changes/Elasticsearch: Difference between revisions