[Apiman-user] Elastic search upgrade

[Eric Wittmann]

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/20170321/135fae27/attachment.html