[Apiman-user] Elastic search upgrade

[Balu S]

perfect! Thanks Eric.

On Tue, Mar 21, 2017 at 7:49 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> In reality, the default embedded instance of Elasticsearch is just a
> separate WAR deployed to Wildfly.  It's just there for convenience in the
> quickstart - not intended to go into production.  In order to remove it,
> all you need to do is remove the apiman-es.war file from wildfly's
> deployments directory:
>
>
> [ewittman at host ~]$ cd ~/apiman-1.2.9.Final/wildfly-
> 10.1.0.Final/standalone/deployments/
> [ewittman at host deployments]$ rm apiman-es.war
>
>
> Restart Wildfly, and you're done!  :)
>
> -Eric
>
>
> On Tue, Mar 21, 2017 at 1:51 PM, Balu S <sbalu27 at gmail.com> wrote:
>
>> Hi Eric,
>> Thanks for your response.
>>
>> One question though. I have noticed that during the server startup, even
>> though we specify standalone ES instance running (port configured in
>> apiman.properties), the default embedded instance is anyway started as well.
>>
>> 2017-03-21 18:42:21,915 INFO  [org.elasticsearch.http] (ServerService
>> Thread Pool -- 64) [Norrin Radd] bound_address {inet[/10.12.129.105:19201]},
>> publish_address {inet[/1x.xx.xxx.1xx:19201]}
>>
>> http://localhost:19201/_nodes/?pretty -- works  (shows apiman specific
>> cluster)
>>
>> http://localhost:19200/_nodes/?pretty -- works (shows application
>> cluster)
>>
>> So ultimately. there are two ES instances running. Although during the
>> actual operation It seems to use the standalone ES instance that is
>> mentioned in apiman.properties. But why does the need to start embedded
>> instance if there is already instance is running ?
>>
>> regards
>> Balu.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 17, 2017 at 5:33 PM, Eric Wittmann <eric.wittmann at redhat.com>
>> wrote:
>>
>>> Glad that you found an acceptable workaround.  If anyone on this list is
>>> interested in identifying the list of incompatibilities between ES versions
>>> (so that we can upgrade support in apiman to the latest version) then we'd
>>> be happy to make those changes.
>>>
>>> As I'm sure everyone is already aware, the full apiman solution is now
>>> in maintenance-only mode.  This means that major functionality will not be
>>> added (by us).  However, with some community support for something like
>>> this, I think we would be able to make time for it.
>>>
>>> Please note that Marc (msavy) continues to actively work on the Gateway,
>>> with a focus on releasing (soon) a vert.x based version.  So the project
>>> isn't entirely silent!  :)
>>>
>>> -Eric
>>>
>>>
>>> On Fri, Mar 17, 2017 at 9:51 AM, Balu S <sbalu27 at gmail.com> wrote:
>>>
>>>> Ok, So option 3) is not straightforward. The build fails as there is
>>>> bunch of API incompatibility between 1.7 and 2.4 versions. Unless one
>>>> wiling to refactor the apiman-es source to use 2.4 API or may be latest 5.2.
>>>>
>>>> I have gone ahead with option 1 and used a separate ES instance running
>>>> with 2.4.4 (cannot go higher than this version due to incompatibility with
>>>> bundled ES API in apiman) version and it seems fine. Since I'm not worried
>>>> about the old indices, this looks like straightforward option.
>>>>
>>>> But if someone want to use old indices, then you may need to dig deeper
>>>> to re-index may be (?).
>>>>
>>>> regards
>>>> Balu
>>>>
>>>> On Thu, Mar 16, 2017 at 10:06 AM, Balu S <sbalu27 at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>> I'm trying to gather metrics (using Kibana tool) from the ES instance
>>>>> that is being used by apiman. But what I found is the ES instance that is
>>>>> bundled inside the apiman is 1.7.x version which seems to be too old for
>>>>> current trending tools to index upon. Of course we can use old versions of
>>>>> those tools, for ex. Kibana 4.1.x version to index and gather metrics. But
>>>>> the older version are limited in functionality and I would like to use the
>>>>> latest if possible.
>>>>>
>>>>> Hence I have following options.
>>>>>
>>>>>   1) Use separate ElasticSearch instance with latest versions and
>>>>> update apiman.properties to point to this instance. And with this new
>>>>> version instance, I can use the latest tools.
>>>>>
>>>>>    Question : Do you think the ES API 1.7.x is compatible and write
>>>>> indices to ES database running in latest version ?
>>>>>
>>>>>  2) Migrate the ES indices to new versions. But the below article,
>>>>> clearly says that the ES version must be at least 2.4.x for smooth
>>>>> migration using their migration tool.
>>>>>
>>>>> https://www.elastic.co/guide/en/elasticsearch/reference/curr
>>>>> ent/reindex-upgrade.html
>>>>>
>>>>> 3) Upgrade bundled ES API 1.7.x to 5.2.x (latest version) or at least
>>>>> 2.4.x version
>>>>>
>>>>>
>>>>> I think it is practical to upgrade bundled ES version to 2.4.x at
>>>>> least (if not for latest 5.2.x) just to make it compatible for migrating
>>>>> indices easily.
>>>>>
>>>>> What are your thoughts? I'm happy to see any alternative options other
>>>>> than mentioned above. Thanks.
>>>>>
>>>>> regards
>>>>> Balu
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170322/e2aca9ff/attachment-0001.html