So from my reading essentially the first question needs to answered/and voted
on is:
Is Apache Kafka Community only about the Core or does the apache community also
support some subprojects (and just we need some better way to manage this)
If vote for Core only wins, then the following should be removed:
Kafka Connect
Kafka Stream
If vote for Core only loses (aka we will support subprojects) then:
We should look to add Kafka Rest
And we should look to see how we can manage better govern and manage submodules.
A good example which id propose here is how some other communities in Apache do
this.
Each Module has a Module Management Committee(MMC), this is like almost the PMC
but at a per module basis.
This MMC should essentially hold the binding votes for that module.
The MMC should be made up of a single representative from each organisation
(so no single organisation can fully veto the community it has to a genuine
consenus)
The MMC requires at least 3 members (so there cant be a tied vote on 2)
For a new Module to be added a MMC committee should be sought
A new Module is only capable of being added if the above requirements can be
met (e.g. 3 people wishing to step up, from 3 organisations) so that only
actively support modules would be added
The PMC reviews each module every 6months or Year. If MMC is inactive, a
vote/call to find replacements if raised, if none are forthcoming dropping the
MMC to less than 3 then the module moves to "the attic" (very much like apache
attic but a little more aggressively)
This way the PMC does not need to micro manage every module
We only add modules where some amount of active support and maintenance and use
is provided by the community
We have an automatic way to retire old or inactive projects.
Thoughts?
Mike
________________________________________
From: Harsha Ch <harsha...@gmail.com>
Sent: Thursday, October 20, 2016 10:26 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-80: Kafka REST Server
Jay,
REST API is something every user is in need of. If the argument is to
clone and write your API, this will do a disservice to the users as they
now have to choose one vs. others instead of keeping one API that is
supported in Kafka community.
"Pre-emptively re-creating another
REST layer when it seems like we all quite agree on what needs to be done
and we have an existing code base for HTTP/Kafka access that is heavily
used in production seems quite silly."
Exactly our point. Why can't we develop this in Apache Kafka
community? Instead of us open sourcing another GitHub project and creating
a divide in users and another version of API. Let's build this in Kafka
Community and use the governance model that is proven to provide vendor
free user driven consensus features. The argument that is adding this REST
server to Kafka will affect the agility of the project doesn't mak sense.
It looks like your argument is either we develop all these small tools or
none at all. We as a community need to look at supporting critical
tools/API. Instead of dividing this project into individual external
communities. We should build this as part of Kafka which best serves the
needs of users.
The Streams and Connect projects that were pushed into Kafka could
have been left in their own Github projects based on your arguments. What
about the REST API is so different that such that it should stay out of the
Kafka project? From my experience, more users are asking for the REST API.
Thanks,
Harsha
On Wed, Oct 12, 2016 at 8:03 AM Jay Kreps <j...@confluent.io> wrote:
> I think the questions around governance make sense, I think we should
> really clarify that to make the process more clear so it can be fully
> inclusive.
>
> The idea that we should not collaborate on what is there now, though,
> because in the future we might disagree about direction does not really
> make sense to me. If in the future we disagree, that is the beauty of open
> source, you can always fork off a copy of the code and start an independent
> project either in Apache or elsewhere. Pre-emptively re-creating another
> REST layer when it seems like we all quite agree on what needs to be done
> and we have an existing code base for HTTP/kafka access that is heavily
> used in production seems quite silly.
>
> Let me give some background on how I at least think about these things.
> I've participated in open source projects out of LinkedIn via github as
> well as via the ASF. I don't think there is a "right" answer to how to do
> these but rather some tradeoffs. We thought about this quite a lot in the
> context of Kafka based on the experience with the Hadoop ecosystem as well
> as from other open source communities.
>
> There is a rich ecosystem around Kafka. Many of the projects are quite
> small--single clients or tools that do a single thing well--and almost none
> of them are top level apache projects. I don't think trying to force each
> of these to turn into independent Apache projects is necessarily the best
> thing for the ecosystem.
>
> My observation of how this can go wrong is really what I think has happened
> to the Hadoop ecosystem. There you see quite a zoo of projects which all
> drift apart and don't quite work together well. Coordinating even simple
> changes and standardization across these is exceptionally difficult. The
> result is a bit of a mess for users--the pieces just don't really come
> together very well. This makes sense for independent infrastructure systems
> (Kudu vs HDFS) but I'm not at all convinced that doing this for every
> little tool or helper library has lead to a desirable state. I think the
> mode of operating where the Hadoop vendors spawn off a few new Apache
> projects for each new product initiative, especially since often that
> project is only valued by that vendor (and the other vendor has a different
> competing Apache project) doesn't necessarily do a better job at producing
> high quality communities or high quality software.
>
> These tools/connects/clients/proxies and other integration pieces can take
> many forms, but my take of what makes one of these things good is that it
> remains simple, does its one thing well, and cleaves as closely as possible
> to the conventions for Kafka itself--i.e. doesn't invent new ways of
> monitoring, configuring, etc. For the tools we've contributed we've tried
> really hard to make them consistent with Kafka as well as with each other
> in how testing, configuration, monitoring, etc works.
>
> I think what Apache does superbly well is create a community for managing a
> large infrastructure layer like Kafka in a vendor independent way. What I
> think is less successful is attempting to form full and independent apache
> communities around very simple single purpose tools, especially if you hope
> for these to come together into a cohesive toolset across multiple such
> tools. Much of what Apache does--create a collective decision making
> process for resolving disagreement, help to trademark and protect the marks
> of the project, etc just isn't that relevant for simple single-purpose
> tools.
>
> So my take is there are a couple of options:
>
> 1. We can try to put all the small tools into the Apache Project. I
> think this is not the right approach as there is simply too many of
> them,
> many in different languages, serving different protocols, integrating
> with
> particular systems, and a single community can't effectively maintain
> them
> all. Doing this would significantly slow the progress of the Kafka
> project.
> As a protocol for messaging, I don't really see a case for including
> REST
> but not MQTT or AMQP which are technically much better suited to
> messaging
> and both are widely used for that.
> 2. We can treat ecosystem projects that aren't top level Apache projects
> as invalid and try to recreate them all as Apache projects. Honestly,
> though, if you go to the Kafka ecosystem page virtually none of the most
> popular add-ons to Kafka are Apache projects. The most successful
> things in
> the Kafka ecosystem such as Yahoo Manager, librdkafka, a number of other
> clients, as well as the existing REST layer have succeeded at developing
> communities that actively contribute and use these pieces and I don't
> know
> that that is a bad thing unless that community proves to be uninclusive,
> unresponsive, or goes in a bad technical direction--and those are
> failure
> modes that all open source efforts face.
> 3. We can do what I think makes the most sense and try to work with the
> projects that exist in the ecosystem and if the project doesn't have a
> responsive community or wants to go in a different direction fork or
> recreate that work.
>
> Of course any person can choose whatever of these options they want. But
> from my point of view, option (3) has been the path of the community so far
> and I think it has been quite successful.
>
> -Jay
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 11, 2016 at 10:33 PM, Harsha Chintalapani <ka...@harsha.io>
> wrote:
>
> > Neha,
> > "But I haven't seen any community emails or patches being submitted by
> you
> > guys, so I'm wondering why you are concerned about whether the community
> is
> > open to accepting patches or not."
> >
> > I think you are talking about contributing patches to this repository
> > right? https://github.com/confluentinc/kafka-rest . All I am saying
> > the guidelines/governance model is not clear on the project and I guess
> its
> > driven by opening a github issue request. Its the repository owned by
> > confluent and as much I appreciate that the features we mentioned are in
> > the roadmap and welcoming us to contribute to the project. It doesn't
> > gurantee what we want to add in the furture will be in your roadmap.
> >
> > Hence the reason having it part of Kafka community will help a lot as
> other
> > users can participate in the discussions. We are happy to drive any
> > feature additions through KIPs which gives everyone a chance to
> participate
> > and add to the discussions.
> >
> > Thanks,
> > Harsha
> >
> > On Fri, Oct 7, 2016 at 11:52 PM Michael Pearce <michael.pea...@ig.com>
> > wrote:
> >
> > > +1
> > >
> > > I agree on the governance comments whole heartedly.
> > >
> > > Also i agree about the contribution comments made earlier in the
> thread,
> > i
> > > personally am less likely to spend any of mine, or give project time
> > within
> > > my internal projects to developers contributing to another commercial
> > > companies project even so technically open source, as then there is
> that
> > > commercial companies interest will always prevail and essentially can
> > > always have a final vote where disagreement. Im sure they never intend
> > to,
> > > but there is that true reality. This is why we have community open
> source
> > > projects.
> > >
> > > I can find many different implementations now of a rest endpoint on
> > > GitHub, BitBucket etc. Each one has their benefits and disadvantages in
> > > their implementation. By making / providing one this would bring
> together
> > > these solutions, unifying those developers and also bringing the best
> of
> > > all.
> > >
> > > I understand the concern on the community burden adding/supporting more
> > > surface area for every client. But something like REST is universal and
> > > worthy to be owned by the community.
> > >
> > > Mike
> > >
> > >
> > > ________________________________________
> > > From: Andrew Schofield <andrew_schofield_j...@outlook.com>
> > > Sent: Saturday, October 8, 2016 1:19 AM
> > > To: dev@kafka.apache.org
> > > Subject: Re: [DISCUSS] KIP-80: Kafka REST Server
> > >
> > > There's a massive difference between the governance of Kafka and the
> > > governance of the REST proxy.
> > >
> > > In Kafka, there is a broad community of people contributing their
> > opinions
> > > about future enhancements in the form of KIPs. There's some really deep
> > > consideration that goes into some of the trickier KIPs. There are
> people
> > > outside Confluent deeply knowledgeable in Kafka and building the
> > > reputations to become committers. I get the impression that the roadmap
> > of
> > > Kafka is not really community-owned (what's the big feature for Kafka
> > 0.11,
> > > for example), but the conveyor belt of smaller features in the form of
> > KIPs
> > > works nicely. It's a good example of open-source working well.
> > >
> > > The equivalent for the REST proxy is basically issues on GitHub. The
> > > roadmap is less clear. There's not really a community properly engaged
> in
> > > the way that there is with Kafka. So, you could say that it's clear
> that
> > > fewer people are interested, but I think the whole governance thing
> is a
> > > big barrier to engagement. And it's looking like it's getting out of
> > date.
> > >
> > > In technical terms, I can think of two big improvements to the REST
> > proxy.
> > > First, it needs to use the new consumer API so that it's possible to
> > secure
> > > connections between the REST proxy and Kafka. I don't care too much
> which
> > > method calls it uses actually uses to consume messages, but I do care
> > that
> > > I cannot secure connections because of network security rules. Second,
> > > there's an affinity between a consumer and the instance of the REST
> proxy
> > > to which it first connected. Kafka itself avoids this kind of affinity
> > for
> > > good reason, and in the name of availability the REST proxy should too.
> > > These are natural KIPs.
> > >
> > > I think it would be good to have the code for the REST proxy
> contributed
> > > to Apache Kafka so that it would be able to be developed in the same
> way.
> > >
> > > Andrew Schofield
> > >
> > > From: Suresh Srinivas <sur...@hortonworks.com>
> > > Sent: 07 October 2016 22:41:52
> > > To: dev@kafka.apache.org
> > > Subject: Re: [DISCUSS] KIP-80: Kafka REST Server
> > >
> > > ASF already gives us a clear framework and governance model for
> community
> > > development. This is already understood by the people contributing to
> > > Apache Kafka project, and they are the same people who want to
> contribute
> > > to the REST server capability as well. Everyone is in agreement on the
> > > need for collaborating on this effort. So why not contribute the code
> to
> > > Apache Kafka. This will help avoid duplication of effort and forks that
> > > may crop up, hugely benefitting the user community. This will also
> avoid
> > > having to define a process similar to ASF on a GitHub project and
> instead
> > > there is a single community with clear understanding community process
> as
> > > defined in ASF.
> > >
> > > As others have said, this is an important capability for Apache Kafka.
> It
> > > is worth maintaining this as a part of the project.
> > >
> > > Regards,
> > > Suresh
> > >
> > > On 10/6/16, 8:32 AM, "Ofir Manor" <ofir.ma...@equalum.io> wrote:
> > >
> > > >I personally think it would be quite wasteful to re-implement the REST
> > > >gateway just because that an actively-maintained piece of
> > Apache-licensed
> > > >software is not governed directly by the Apache Kafka community...
> While
> > > >kafka-rest repo is owned by Confluent, the contributors including the
> > main
> > > >one are also part of the Apache Kafka community, so there is a chance
> > to
> > > >work this out.
> > > >
> > > >However, there are two valid concerns here that could be addressed,
> > around
> > > >community and accessibility:
> > > >>> What we are worried about is a project
> > > >>> that's not maintained in a community. So the process of accepting
> > > >>>patches
> > > >>> and priorities is not clear, and it's not developed in Apache
> > > >>>community.
> > > >>> Not only that, existing REST API project doesn't support new client
> > API
> > > >and
> > > >>> hence there is no security support either.
> > > >
> > > >This might be easy to fix. Maybe Confluent / kafka-rest community can
> > > >clarify that - what is their contribution policy, dev style, roadmap
> > etc.
> > > >If they want, they can make an effort to encourage participation from
> > > >people outside Confluent (easily accept contributions, invite external
> > > >commiters or have open dev process similar to Apache Kafka etc), as
> > there
> > > >is definitely seems to be some interest on the list. That might clear
> > the
> > > >community concern and help kafka-rest project (but that is a
> calculation
> > > >Confluent will have to make).
> > > >
> > > >The other, independent, concern is that REST is something that is
> > expected
> > > >to be available out of the box with Kafka. I personally don't feel
> > > >strongly
> > > >about it (better use proper, efficient APIs from day one), though it
> is
> > > >definitely way smaller than adding a stream processing engine to the
> > > >project :)
> > > >Again,the kafka-rest "community" could take steps to make it even
> easier
> > > >to
> > > >install, configure and run kafka-rest for new users on vanilla Apache
> > > >Kafka
> > > >(outside the Confluent platform), if they wish that (or welcome
> > > >contributions to that end), but that is up to them.
> > > >Finally, if after the above steps were taken there would still a
> strong
> > > >desire to include a great rest gateway with Apache Kafka, I assume the
> > > >community could hypothetically fork the existing kafka-rest into an
> > Apache
> > > >Kafka subproject and maintain it "within Apache" instead of
> implementing
> > > >it
> > > >from scratch (though I'm not a lawyer etc) - but I cannot imagine it
> > > >happen
> > > >without Confluent blessing, and I think that is likely much less
> optimal
> > > >(pulling in other Confluent / Apache licensed dependencies) than
> having
> > a
> > > >separate external community around kafka-rest.
> > > >
> > > >
> > > >Just my two cents,
> > > >
> > > >
> > > >Ofir Manor
> > > >
> > > >Co-Founder & CTO | Equalum
> > > >
> > > >Mobile: +972-54-7801286 <+972%2054-780-1286> <+972%2054-780-1286> |
> Email:
> > > ofir.ma...@equalum.io
> > > >
> > > >On Sun, Oct 2, 2016 at 11:23 PM, Harsha Chintalapani <ka...@harsha.io
> >
> > > >wrote:
> > > >
> > > >> Neha & Jay,
> > > >> We did look at the open source alternatives. Our
> > > >>concern
> > > >> is what's the patch acceptance and adding features/ bug-fixes to the
> > > >> existing project under a Github (although it's licensed under Apache
> > > >>2.0).
> > > >> It would be great if that project made available under Apache and
> > > >>driven by
> > > >> the community. Adding to the above, not all Kafka users are
> > interested
> > > >>in
> > > >> using the Java client API, they would like to have simple REST API
> > where
> > > >> they can code against using any language. I do believe this adds
> value
> > > >>to
> > > >> Apache Kafka in itself.
> > > >>
> > > >> "For 1, I don't think there is value in giving in to the NIH
> syndrome
> > > >>and
> > > >> reinventing the wheel. What I'm looking for is a detailed comparison
> > of
> > > >>the
> > > >> gaps and why those can't be improved in the REST proxy that already
> > > >>exists
> > > >> and is actively maintained."
> > > >>
> > > >> We are not looking at this as NIH. What we are worried about is a
> > > >>project
> > > >> that's not maintained in a community. So the process of accepting
> > > >>patches
> > > >> and priorities is not clear, and it's not developed in Apache
> > community.
> > > >> Not only that, existing REST API project doesn't support new client
> > API
> > > >>and
> > > >> hence there is no security support either.
> > > >> We don't know the timeline when that's made available. We would like
> > to
> > > >>add
> > > >> admin functionality into the REST API. So the Roadmap of that
> project
> > is
> > > >> not driven by Apache.
> > > >>
> > > >>
> > > >> "This doesn't materially have an impact on expanding the usability
> of
> > > >> Kafka. In my experience, REST proxy + Java clients only cover
> ~50%
> > of
> > > >> all
> > > >> Kafka users, and maybe 10% of those are the ones who will use the
> > > >>REST
> > > >> proxy. The remaining 50% are non-java client users (C, python,
> go,
> > > >>node
> > > >> etc)."
> > > >>
> > > >> REST API is most often asked feature in my interactions with Kafka
> > > >>users.
> > > >> In an organization, There will be independent teams who will write
> > their
> > > >> Kafka clients using different language libraries available today,
> and
> > > >> there is no way to standardize this. Instead of supporting several
> > > >> different client libraries users will be interested in using a REST
> > API
> > > >> server. The need for a REST API will only increase as more and more
> > > >>users
> > > >> start using Kafka.
> > > >>
> > > >> "More surface area means more work to keep things consistent.
> Failure
> > > >> to do that has, in fact, hurt the user experience."
> > > >> Having myriad Kafka client GitHub projects that support different
> > > >>languages
> > > >> hurts the user experience and pushes burden to maintain these
> > libraries.
> > > >> REST API is a simple code base that uses existing java client
> > libraries
> > > >>to
> > > >> make life easier for the users.
> > > >>
> > > >> Thanks,
> > > >> Harsha
> > > >>
> > > >> On Sat, Oct 1, 2016 at 10:41 AM Neha Narkhede <n...@confluent.io>
> > > wrote:
> > > >>
> > > >> > Manikumar,
> > > >> >
> > > >> > Thanks for sharing the proposal. I think there are 2 parts to this
> > > >> > discussion -
> > > >> >
> > > >> > 1. Should we rewrite a REST proxy given that there is a
> > > >>feature-complete,
> > > >> > open-source and actively maintained REST proxy in the community?
> > > >> > 2. Does adding a REST proxy to Apache Kafka make us more agile and
> > > >> maintain
> > > >> > the high-quality experience that Kafka users have today?
> > > >> >
> > > >> > For 1, I don't think there is value in giving in to the NIH
> syndrome
> > > >>and
> > > >> > reinventing the wheel. What I'm looking for is a detailed
> comparison
> > > >>of
> > > >> the
> > > >> > gaps and why those can't be improved in the REST proxy that
> already
> > > >> exists
> > > >> > and is actively maintained. For example, we depend on zkClient and
> > > >>have
> > > >> > found as well as fixed several bugs by working closely with the
> > people
> > > >> who
> > > >> > maintain zkClient. This should be possible for REST proxy as well,
> > > >>right?
> > > >> >
> > > >> > For 2, I'd like us to review our history of expanding the surface
> > > >>area to
> > > >> > add more clients in the past. Here is a summary -
> > > >> >
> > > >> > - This doesn't materially have an impact on expanding the
> > > >>usability of
> > > >> > Kafka. In my experience, REST proxy + Java clients only cover
> > ~50%
> > > >>of
> > > >> > all
> > > >> > Kafka users, and maybe 10% of those are the ones who will use
> the
> > > >>REST
> > > >> > proxy. The remaining 50% are non-java client users (C, python,
> > go,
> > > >> node
> > > >> > etc).
> > > >> > - People are a lot more excited about promising to contribute
> > while
> > > >> > adding the surface area but not on an ongoing basis down the
> > line.
> > > >> > - More surface area means more work to keep things consistent.
> > > >>Failure
> > > >> > to do that has, in fact, hurt the user experience.
> > > >> > - More surface area hurts agility. We want to do a few things
> > > >>really
> > > >> > well as well as be agile to be able to build on our core
> > > >>competency.
> > > >> >
> > > >> >
> > > >> > On Sat, Oct 1, 2016 at 5:38 AM Manikumar <
> manikumar.re...@gmail.com
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hi Jay,
> > > >> > >
> > > >> > > Thanks for your reply.
> > > >> > >
> > > >> > > I agree that we can not add all the clients/tools available in
> > > >> ecosystem
> > > >> > > page to Kafka repo itself. But we feel REST Interface is
> different
> > > >>from
> > > >> > > other clients/tools. Since any language that can work with HTTP
> > can
> > > >> > > easily integrate with this interface, Having an "official" REST
> > > >> > > interface helps user community. This also helps us to integrate
> > well
> > > >> > > with external management and provisioning tools. Apache Kafka
> > > >>release
> > > >> > > with Java clients + REST interface is sufficient for most of the
> > > >>user
> > > >> > > deployments/requirements. This helps users to deal with less
> > number
> > > >> > > of distributions/builds.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Manikumar
> > > >> > >
> > > >> > >
> > > >> > > On Sat, Oct 1, 2016 at 4:24 AM, Jay Kreps <j...@confluent.io>
> > wrote:
> > > >> > >
> > > >> > > > Hey guys,
> > > >> > > >
> > > >> > > > There's already a REST interface maintained as a separate
> > > >> project--it's
> > > >> > > > open source and apache licensed and actively maintained (
> > > >> > > > https://github.com/confluentinc/kafka-rest). What is wrong
> with
> > >
> > >
> > >
> > > GitHub - confluentinc/kafka-rest: REST Proxy for Kafka
> > > github.com
> > > The Kafka REST Proxy provides a RESTful interface to a Kafka cluster.
> It
> > > makes it easy to produce and consume messages, view the state of the
> > > cluster, and ...
> > >
> > > >> that?
> > > >> > > You
> > > >> > > > mentioned that there was some compatibility concern, but
> > > >> compatibility
> > > >> > > has
> > > >> > > > to do with the consumer protocol guarantees not the repo the
> > code
> > > >>is
> > > >> > in,
> > > >> > > > right? Not sure that concern makes sense.
> > > >> > > >
> > > >> > > > We could argue for adding pretty much anything and everything
> in
> > > >>the
> > > >> > > > ecosystem page in Kafka itself but I'm not sure that would
> make
> > > >>the
> > > >> > > project
> > > >> > > > more agile.
> > > >> > > >
> > > >> > > > -Jay
> > > >> > > >
> > > >> > > > On Wed, Sep 28, 2016 at 12:04 AM, Manikumar <
> > > >> manikumar.re...@gmail.com
> > > >> > >
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Hi Kafka Devs,
> > > >> > > > >
> > > >> > > > > I created KIP-80 to add Kafka REST Server to Kafka
> Repository.
> > > >> > > > >
> > > >> > > > > There are already open-source alternatives are available.
> But
> > > >>we
> > > >> > would
> > > >> > > > > like to add REST server that
> > > >> > > > > many users ask for under Apache Kafka repo. Many data Infra
> > > >>tools
> > > >> > comes
> > > >> > > > up
> > > >> > > > > with Rest Interface.
> > > >> > > > > It is useful to have inbuilt Rest API support for Produce,
> > > >>Consume
> > > >> > > > messages
> > > >> > > > > and admin interface for
> > > >> > > > > integrating with external management and provisioning
> > tools.This
> > > >> will
> > > >> > > > also
> > > >> > > > > allow the maintenance of
> > > >> > > > > REST server and adding new features makes it easy because
> > apache
> > > >> > > > community.
> > > >> > > > >
> > > >> > > > > The KIP wiki is the following:
> > > >> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > >> > > > > 80%3A+Kafka+Rest+Server
> > > >> > > > >
> > > >> > > > > Your comments and feedback are welcome.
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Manikumar
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > --
> > > >> > Thanks,
> > > >> > Neha
> > > >> >
> > > >>
> > > The information contained in this email is strictly confidential and
> for
> > > the use of the addressee only, unless otherwise indicated. If you are
> not
> > > the intended recipient, please do not read, copy, use or disclose to
> > others
> > > this message or any attachment. Please also notify the sender by
> replying
> > > to this email or by telephone (+44(020 7896 0011) and then delete the
> > email
> > > and any copies of it. Opinions, conclusion (etc) that do not relate to
> > the
> > > official business of this company shall be understood as neither given
> > nor
> > > endorsed by it. IG is a trading name of IG Markets Limited (a company
> > > registered in England and Wales, company number 04008957) and IG Index
> > > Limited (a company registered in England and Wales, company number
> > > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> > > London EC4R 2YA. Both IG Markets Limited (register number 195355) and
> IG
> > > Index Limited (register number 114059) are authorised and regulated by
> > the
> > > Financial Conduct Authority.
> > >
> >
>
The information contained in this email is strictly confidential and for the
use of the addressee only, unless otherwise indicated. If you are not the
intended recipient, please do not read, copy, use or disclose to others this
message or any attachment. Please also notify the sender by replying to this
email or by telephone (+44(020 7896 0011) and then delete the email and any
copies of it. Opinions, conclusion (etc) that do not relate to the official
business of this company shall be understood as neither given nor endorsed by
it. IG is a trading name of IG Markets Limited (a company registered in England
and Wales, company number 04008957) and IG Index Limited (a company registered
in England and Wales, company number 01190902). Registered address at Cannon
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited
(register number 195355) and IG Index Limited (register number 114059) are
authorised and regulated by the Financial Conduct Authority.
