Re: [Apiman-user] Elastic search upgrade

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> >