Mark,
For non-Java clients an option could be to expose JMX via REST API using
Jolokia as an adapter. This may be helpful:
http://stackoverflow.com/questions/5106847/access-jmx-agents-from-non-java-clients
Joel,
I'm not familiar with Kafka build infrastructure, but e. g. Jenkins can
easily propagate Git commit hash it's building to the build runtime using a
predefined build parameter, GIT_COMMIT. Most likely there is a similar
option in other CI tools. This value can then be put into a properties
file. E. g. Maven can do this using resource filtering mechanism. I believe
Gradle should be even more flexible in this regard.
For non-CI builds things are more tricky, but the idea might be to read git
CLI output. This command would give the "current" commit hash: "git
rev-parse HEAD" which again can be passed to the build runtime using a
property/parameter. Here I make an assumption that Git is installed on the
build machine, but this will hold true in most cases I can imagine.
- Yury
2014-11-12 22:11 GMT+03:00 Mark Roberts <wiz...@gmail.com>:
> I haven't worked much with JMX before, but some quick googling (10-20
> minutes) is very inconclusive as to how I would go about getting the server
> version I'm connecting to from a Python client. Can someone please
> reassure me that it's relatively trivial for non Java clients to query JMX
> for the server version of every server in the cluster? Is there a reason
> not to include this in the API itself?
>
> -Mark
>
> On Wed, Nov 12, 2014 at 9:50 AM, Joel Koshy <jjkosh...@gmail.com> wrote:
>
> > +1 on the JMX + gradle properties. Is there any (seamless) way of
> > including the exact git hash? That would be extremely useful if users
> > need help debugging and happen to be on an unreleased build (say, off
> > trunk)
> >
> > On Wed, Nov 12, 2014 at 09:34:35AM -0800, Gwen Shapira wrote:
> > > Actually, Jun suggested exposing this via JMX.
> > >
> > > On Wed, Nov 12, 2014 at 9:31 AM, Gwen Shapira <gshap...@cloudera.com>
> > wrote:
> > >
> > > > Good question.
> > > >
> > > > The server will need to expose this in the protocol, so Kafka clients
> > will
> > > > know what they are talking to.
> > > >
> > > > We may also want to expose this in the producer and consumer, so
> people
> > > > who use Kafka's built-in clients will know which version they have in
> > the
> > > > environment.
> > > >
> > > >
> > > >
> > > > On Wed, Nov 12, 2014 at 9:09 AM, Mark Roberts <wiz...@gmail.com>
> > wrote:
> > > >
> > > >> Just to be clear: this is going to be exposed via some Api the
> clients
> > > >> can call at startup?
> > > >>
> > > >>
> > > >> > On Nov 12, 2014, at 08:59, Guozhang Wang <wangg...@gmail.com>
> > wrote:
> > > >> >
> > > >> > Sounds great, +1 on this.
> > > >> >
> > > >> >> On Tue, Nov 11, 2014 at 1:36 PM, Gwen Shapira <
> > gshap...@cloudera.com>
> > > >> wrote:
> > > >> >>
> > > >> >> So it looks like we can use Gradle to add properties to manifest
> > file
> > > >> and
> > > >> >> then use getResourceAsStream to read the file and parse it.
> > > >> >>
> > > >> >> The Gradle part would be something like:
> > > >> >> jar.manifest {
> > > >> >> attributes('Implementation-Title': project.name,
> > > >> >> 'Implementation-Version': project.version,
> > > >> >> 'Built-By': System.getProperty('user.name'),
> > > >> >> 'Built-JDK': System.getProperty('java.version'),
> > > >> >> 'Built-Host': getHostname(),
> > > >> >> 'Source-Compatibility': project.sourceCompatibility,
> > > >> >> 'Target-Compatibility': project.targetCompatibility
> > > >> >> )
> > > >> >> }
> > > >> >>
> > > >> >> The code part would be:
> > > >> >>
> > > >> >>
> > > >>
> >
> this.getClass().getClassLoader().getResourceAsStream("/META-INF/MANIFEST.MF")
> > > >> >>
> > > >> >> Does that look like the right approach?
> > > >> >>
> > > >> >> Gwen
> > > >> >>
> > > >> >> On Tue, Nov 11, 2014 at 10:43 AM, Bhavesh Mistry <
> > > >> >> mistry.p.bhav...@gmail.com
> > > >> >>> wrote:
> > > >> >>
> > > >> >>> If is maven artifact then you will get following pre-build
> > property
> > > >> file
> > > >> >>> from maven build called pom.properties under
> > > >> >>> /META-INF/maven/groupid/artifactId/pom.properties folder.
> > > >> >>>
> > > >> >>> Here is sample:
> > > >> >>> #Generated by Maven
> > > >> >>> #Mon Oct 10 10:44:31 EDT 2011
> > > >> >>> version=10.0.1
> > > >> >>> groupId=com.google.guava
> > > >> >>> artifactId=guava
> > > >> >>>
> > > >> >>> Thanks,
> > > >> >>>
> > > >> >>> Bhavesh
> > > >> >>>
> > > >> >>> On Tue, Nov 11, 2014 at 10:34 AM, Gwen Shapira <
> > gshap...@cloudera.com
> > > >> >
> > > >> >>> wrote:
> > > >> >>>
> > > >> >>>> In Sqoop we do the following:
> > > >> >>>>
> > > >> >>>> Maven runs a shell script, passing the version as a parameter.
> > > >> >>>> The shell-script generates a small java class, which is then
> > built
> > > >> >> with a
> > > >> >>>> Maven plugin.
> > > >> >>>> Our code references this generated class when we expose
> > > >> "getVersion()".
> > > >> >>>>
> > > >> >>>> Its complex and ugly, so I'm kind of hoping that there's a
> > better way
> > > >> >> to
> > > >> >>> do
> > > >> >>>> it :)
> > > >> >>>>
> > > >> >>>> Gwen
> > > >> >>>>
> > > >> >>>>> On Tue, Nov 11, 2014 at 9:42 AM, Jun Rao <jun...@gmail.com>
> > wrote:
> > > >> >>>>>
> > > >> >>>>> Currently, the version number is only stored in our build
> config
> > > >> >> file,
> > > >> >>>>> gradle.properties. Not sure how we can automatically extract
> it
> > and
> > > >> >>>> expose
> > > >> >>>>> it in an mbean. How do other projects do this?
> > > >> >>>>>
> > > >> >>>>> Thanks,
> > > >> >>>>>
> > > >> >>>>> Jun
> > > >> >>>>>
> > > >> >>>>> On Tue, Nov 11, 2014 at 7:05 AM, Otis Gospodnetic <
> > > >> >>>>> otis.gospodne...@gmail.com> wrote:
> > > >> >>>>>
> > > >> >>>>>> Hi Jun,
> > > >> >>>>>>
> > > >> >>>>>> Sounds good. But is the version number stored anywhere from
> > where
> > > >> >> it
> > > >> >>>>> could
> > > >> >>>>>> be gotten?
> > > >> >>>>>>
> > > >> >>>>>> Thanks,
> > > >> >>>>>> Otis
> > > >> >>>>>> --
> > > >> >>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log
> > > >> >>> Management
> > > >> >>>>>> Solr & Elasticsearch Support * http://sematext.com/
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>> On Tue, Nov 11, 2014 at 12:45 AM, Jun Rao <jun...@gmail.com>
> > > >> >> wrote:
> > > >> >>>>>>
> > > >> >>>>>>> Otis,
> > > >> >>>>>>>
> > > >> >>>>>>> We don't have an api for that now. We can probably expose
> this
> > > >> >> as a
> > > >> >>>> JMX
> > > >> >>>>>> as
> > > >> >>>>>>> part of kafka-1481.
> > > >> >>>>>>>
> > > >> >>>>>>> Thanks,
> > > >> >>>>>>>
> > > >> >>>>>>> Jun
> > > >> >>>>>>>
> > > >> >>>>>>> On Mon, Nov 10, 2014 at 7:17 PM, Otis Gospodnetic <
> > > >> >>>>>>> otis.gospodne...@gmail.com> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>>> Hi,
> > > >> >>>>>>>>
> > > >> >>>>>>>> Is there a way to detect which version of Kafka one is
> > running?
> > > >> >>>>>>>> Is there an API for that, or a constant with this value, or
> > > >> >> maybe
> > > >> >>>> an
> > > >> >>>>>>> MBean
> > > >> >>>>>>>> or some other way to get to this info?
> > > >> >>>>>>>>
> > > >> >>>>>>>> Thanks,
> > > >> >>>>>>>> Otis
> > > >> >>>>>>>> --
> > > >> >>>>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log
> > > >> >>>>> Management
> > > >> >>>>>>>> Solr & Elasticsearch Support * http://sematext.com/
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > -- Guozhang
> > > >>
> > > >
> > > >
> >
> >
>
