You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Aldrin Piri <al...@gmail.com> on 2016/03/09 21:28:41 UTC
Establishment of MiNiFi repo and supporting tools
NiFi Community,
Originally discussed in January [1], the MiNiFi agent model was met with
positive feedback. I would like to propose a concerted effort toward the
execution on the ideas presented and establish a basis for incorporation of
the feedback received from, and collaboration with, the community to move
toward our goals of helping with dataflow from the point of its origin.
To that end, I would like to propose the creation of:
-
a separate repository (nifi-minifi),
-
establishment of a MiNiFi JIRA (MINIFI), and
-
production of an associated feature proposals and design documentation
within our Confluence Wiki spaces beyond the initial points outlined by Joe
with some additional proposals architecture and roadmap
The separate JIRA and Git repo map to the existing ASF infrastructure for
projects with similar efforts and will aid in a cleaner release and issue
management process.
Central to the aims of MiNiFi, the tenets of its operation and execution of
dataflow are the same as NiFi itself: security, provenance, and management
of dataflow; helping bring information to NiFi while maintaining the full
extent of its provenance.
Some clarifying points based on the discussion that existed previously:
-
While there may be reuse of NiFi components and some overlap, MiNiFi is
a separate effort that is complementary to but not necessarily directly
compatible with existing components and extensions. Obviously there has
been a lot of great effort which we can reuse, but in striving to be a
smaller footprint, we should not find ourselves beholden to the existing,
core, NiFi architecture.
-
There will exist scenarios where there is an inherent need to go smaller
and closer to the source system. This will take the form of native code
that builds upon the same efforts and items originally developed under the
Java ecosystem.
-
Design should take consideration of disparate execution environments and
provide ways to robustly handle varying means of communication and
exchange. Accordingly, communications both in management of agents and the
transference of data should be neutral to technologies, providing the same
flexibility and adaptation that allows NiFi to communicate with a wide
breadth of systems, protocols, schemas, and formats.
[1]
http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
Re: Establishment of MiNiFi repo and supporting tools
Posted by Matt Burgess <ma...@gmail.com>.
Excellent, thanks!
> On Mar 14, 2016, at 4:57 PM, Aldrin Piri <al...@gmail.com> wrote:
>
> Given the positive response, I have submitted requests for both a new JIRA
> and new Git repository which INFRA has kindly stood up for us. MiNiFi JIRA
> and Git are available at [1] and [2], respectively.
>
> [1] https://issues.apache.org/jira/browse/MINIFI/
> [2] https://git-wip-us.apache.org/repos/asf/nifi-minifi.git
>
> On Fri, Mar 11, 2016 at 1:45 PM, Andy LoPresto <al...@gmail.com>
> wrote:
>
>> +1.
>>
>> Andy LoPresto
>> alopresto.apache@gmail.com
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>> On Mar 11, 2016, at 9:41 AM, Mark Payne <ma...@hotmail.com> wrote:
>>
>> +1 from me as well
>>
>> On Mar 11, 2016, at 8:36 AM, Matt Burgess <ma...@gmail.com> wrote:
>>
>> I'm a +1 as well.
>>
>> On Mar 11, 2016, at 8:26 AM, Tony Kurc <tr...@gmail.com> wrote:
>>
>> Should this be marked as a [VOTE]? In any case, I'm +1
>>
>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
>>
>> All,
>>
>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
>> continuing on with the outlined procedure. If no one objects in the next
>> two days, will look at carrying out the prescribed items listed.
>>
>>
>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>
>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>>
>> NiFi Community,
>>
>> Originally discussed in January [1], the MiNiFi agent model was met with
>> positive feedback. I would like to propose a concerted effort toward the
>> execution on the ideas presented and establish a basis for incorporation
>>
>> of
>>
>> the feedback received from, and collaboration with, the community to move
>> toward our goals of helping with dataflow from the point of its origin.
>>
>> To that end, I would like to propose the creation of:
>>
>> -
>>
>> a separate repository (nifi-minifi),
>> -
>>
>> establishment of a MiNiFi JIRA (MINIFI), and
>> -
>>
>> production of an associated feature proposals and design documentation
>> within our Confluence Wiki spaces beyond the initial points outlined
>>
>> by Joe
>>
>> with some additional proposals architecture and roadmap
>>
>> The separate JIRA and Git repo map to the existing ASF infrastructure for
>> projects with similar efforts and will aid in a cleaner release and issue
>> management process.
>>
>> Central to the aims of MiNiFi, the tenets of its operation and execution
>> of dataflow are the same as NiFi itself: security, provenance, and
>> management of dataflow; helping bring information to NiFi while
>>
>> maintaining
>>
>> the full extent of its provenance.
>>
>> Some clarifying points based on the discussion that existed previously:
>>
>> -
>>
>> While there may be reuse of NiFi components and some overlap, MiNiFi
>> is a separate effort that is complementary to but not necessarily
>>
>> directly
>>
>> compatible with existing components and extensions. Obviously there
>>
>> has
>>
>> been a lot of great effort which we can reuse, but in striving to be a
>> smaller footprint, we should not find ourselves beholden to the
>>
>> existing,
>>
>> core, NiFi architecture.
>> -
>>
>> There will exist scenarios where there is an inherent need to go
>> smaller and closer to the source system. This will take the form of
>>
>> native
>>
>> code that builds upon the same efforts and items originally developed
>>
>> under
>>
>> the Java ecosystem.
>> -
>>
>> Design should take consideration of disparate execution environments
>> and provide ways to robustly handle varying means of communication and
>> exchange. Accordingly, communications both in management of agents
>>
>> and the
>>
>> transference of data should be neutral to technologies, providing the
>>
>> same
>>
>> flexibility and adaptation that allows NiFi to communicate with a wide
>> breadth of systems, protocols, schemas, and formats.
>>
>>
>> [1]
>>
>>
>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>>
>>
>>
>>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Aldrin Piri <al...@gmail.com>.
Given the positive response, I have submitted requests for both a new JIRA
and new Git repository which INFRA has kindly stood up for us. MiNiFi JIRA
and Git are available at [1] and [2], respectively.
[1] https://issues.apache.org/jira/browse/MINIFI/
[2] https://git-wip-us.apache.org/repos/asf/nifi-minifi.git
On Fri, Mar 11, 2016 at 1:45 PM, Andy LoPresto <al...@gmail.com>
wrote:
> +1.
>
> Andy LoPresto
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Mar 11, 2016, at 9:41 AM, Mark Payne <ma...@hotmail.com> wrote:
>
> +1 from me as well
>
> On Mar 11, 2016, at 8:36 AM, Matt Burgess <ma...@gmail.com> wrote:
>
> I'm a +1 as well.
>
> On Mar 11, 2016, at 8:26 AM, Tony Kurc <tr...@gmail.com> wrote:
>
> Should this be marked as a [VOTE]? In any case, I'm +1
>
> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
>
> All,
>
> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
> continuing on with the outlined procedure. If no one objects in the next
> two days, will look at carrying out the prescribed items listed.
>
>
> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>
> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>
> NiFi Community,
>
> Originally discussed in January [1], the MiNiFi agent model was met with
> positive feedback. I would like to propose a concerted effort toward the
> execution on the ideas presented and establish a basis for incorporation
>
> of
>
> the feedback received from, and collaboration with, the community to move
> toward our goals of helping with dataflow from the point of its origin.
>
> To that end, I would like to propose the creation of:
>
> -
>
> a separate repository (nifi-minifi),
> -
>
> establishment of a MiNiFi JIRA (MINIFI), and
> -
>
> production of an associated feature proposals and design documentation
> within our Confluence Wiki spaces beyond the initial points outlined
>
> by Joe
>
> with some additional proposals architecture and roadmap
>
> The separate JIRA and Git repo map to the existing ASF infrastructure for
> projects with similar efforts and will aid in a cleaner release and issue
> management process.
>
> Central to the aims of MiNiFi, the tenets of its operation and execution
> of dataflow are the same as NiFi itself: security, provenance, and
> management of dataflow; helping bring information to NiFi while
>
> maintaining
>
> the full extent of its provenance.
>
> Some clarifying points based on the discussion that existed previously:
>
> -
>
> While there may be reuse of NiFi components and some overlap, MiNiFi
> is a separate effort that is complementary to but not necessarily
>
> directly
>
> compatible with existing components and extensions. Obviously there
>
> has
>
> been a lot of great effort which we can reuse, but in striving to be a
> smaller footprint, we should not find ourselves beholden to the
>
> existing,
>
> core, NiFi architecture.
> -
>
> There will exist scenarios where there is an inherent need to go
> smaller and closer to the source system. This will take the form of
>
> native
>
> code that builds upon the same efforts and items originally developed
>
> under
>
> the Java ecosystem.
> -
>
> Design should take consideration of disparate execution environments
> and provide ways to robustly handle varying means of communication and
> exchange. Accordingly, communications both in management of agents
>
> and the
>
> transference of data should be neutral to technologies, providing the
>
> same
>
> flexibility and adaptation that allows NiFi to communicate with a wide
> breadth of systems, protocols, schemas, and formats.
>
>
> [1]
>
>
> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>
>
>
>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Andy LoPresto <al...@gmail.com>.
+1.
Andy LoPresto
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Mar 11, 2016, at 9:41 AM, Mark Payne <ma...@hotmail.com> wrote:
>
> +1 from me as well
>
>> On Mar 11, 2016, at 8:36 AM, Matt Burgess <ma...@gmail.com> wrote:
>>
>> I'm a +1 as well.
>>
>>> On Mar 11, 2016, at 8:26 AM, Tony Kurc <tr...@gmail.com> wrote:
>>>
>>> Should this be marked as a [VOTE]? In any case, I'm +1
>>>
>>>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
>>>>
>>>> All,
>>>>
>>>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
>>>> continuing on with the outlined procedure. If no one objects in the next
>>>> two days, will look at carrying out the prescribed items listed.
>>>>
>>>>
>>>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>>>
>>>>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>>>
>>>>> NiFi Community,
>>>>>
>>>>> Originally discussed in January [1], the MiNiFi agent model was met with
>>>>> positive feedback. I would like to propose a concerted effort toward the
>>>>> execution on the ideas presented and establish a basis for incorporation
>>>> of
>>>>> the feedback received from, and collaboration with, the community to move
>>>>> toward our goals of helping with dataflow from the point of its origin.
>>>>>
>>>>> To that end, I would like to propose the creation of:
>>>>>
>>>>> -
>>>>>
>>>>> a separate repository (nifi-minifi),
>>>>> -
>>>>>
>>>>> establishment of a MiNiFi JIRA (MINIFI), and
>>>>> -
>>>>>
>>>>> production of an associated feature proposals and design documentation
>>>>> within our Confluence Wiki spaces beyond the initial points outlined
>>>> by Joe
>>>>> with some additional proposals architecture and roadmap
>>>>>
>>>>> The separate JIRA and Git repo map to the existing ASF infrastructure for
>>>>> projects with similar efforts and will aid in a cleaner release and issue
>>>>> management process.
>>>>>
>>>>> Central to the aims of MiNiFi, the tenets of its operation and execution
>>>>> of dataflow are the same as NiFi itself: security, provenance, and
>>>>> management of dataflow; helping bring information to NiFi while
>>>> maintaining
>>>>> the full extent of its provenance.
>>>>>
>>>>> Some clarifying points based on the discussion that existed previously:
>>>>>
>>>>> -
>>>>>
>>>>> While there may be reuse of NiFi components and some overlap, MiNiFi
>>>>> is a separate effort that is complementary to but not necessarily
>>>> directly
>>>>> compatible with existing components and extensions. Obviously there
>>>> has
>>>>> been a lot of great effort which we can reuse, but in striving to be a
>>>>> smaller footprint, we should not find ourselves beholden to the
>>>> existing,
>>>>> core, NiFi architecture.
>>>>> -
>>>>>
>>>>> There will exist scenarios where there is an inherent need to go
>>>>> smaller and closer to the source system. This will take the form of
>>>> native
>>>>> code that builds upon the same efforts and items originally developed
>>>> under
>>>>> the Java ecosystem.
>>>>> -
>>>>>
>>>>> Design should take consideration of disparate execution environments
>>>>> and provide ways to robustly handle varying means of communication and
>>>>> exchange. Accordingly, communications both in management of agents
>>>> and the
>>>>> transference of data should be neutral to technologies, providing the
>>>> same
>>>>> flexibility and adaptation that allows NiFi to communicate with a wide
>>>>> breadth of systems, protocols, schemas, and formats.
>>>>>
>>>>>
>>>>> [1]
>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>>>>
>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Mark Payne <ma...@hotmail.com>.
+1 from me as well
> On Mar 11, 2016, at 8:36 AM, Matt Burgess <ma...@gmail.com> wrote:
>
> I'm a +1 as well.
>
>> On Mar 11, 2016, at 8:26 AM, Tony Kurc <tr...@gmail.com> wrote:
>>
>> Should this be marked as a [VOTE]? In any case, I'm +1
>>
>>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
>>> continuing on with the outlined procedure. If no one objects in the next
>>> two days, will look at carrying out the prescribed items listed.
>>>
>>>
>>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>>
>>>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>>
>>>> NiFi Community,
>>>>
>>>> Originally discussed in January [1], the MiNiFi agent model was met with
>>>> positive feedback. I would like to propose a concerted effort toward the
>>>> execution on the ideas presented and establish a basis for incorporation
>>> of
>>>> the feedback received from, and collaboration with, the community to move
>>>> toward our goals of helping with dataflow from the point of its origin.
>>>>
>>>> To that end, I would like to propose the creation of:
>>>>
>>>> -
>>>>
>>>> a separate repository (nifi-minifi),
>>>> -
>>>>
>>>> establishment of a MiNiFi JIRA (MINIFI), and
>>>> -
>>>>
>>>> production of an associated feature proposals and design documentation
>>>> within our Confluence Wiki spaces beyond the initial points outlined
>>> by Joe
>>>> with some additional proposals architecture and roadmap
>>>>
>>>> The separate JIRA and Git repo map to the existing ASF infrastructure for
>>>> projects with similar efforts and will aid in a cleaner release and issue
>>>> management process.
>>>>
>>>> Central to the aims of MiNiFi, the tenets of its operation and execution
>>>> of dataflow are the same as NiFi itself: security, provenance, and
>>>> management of dataflow; helping bring information to NiFi while
>>> maintaining
>>>> the full extent of its provenance.
>>>>
>>>> Some clarifying points based on the discussion that existed previously:
>>>>
>>>> -
>>>>
>>>> While there may be reuse of NiFi components and some overlap, MiNiFi
>>>> is a separate effort that is complementary to but not necessarily
>>> directly
>>>> compatible with existing components and extensions. Obviously there
>>> has
>>>> been a lot of great effort which we can reuse, but in striving to be a
>>>> smaller footprint, we should not find ourselves beholden to the
>>> existing,
>>>> core, NiFi architecture.
>>>> -
>>>>
>>>> There will exist scenarios where there is an inherent need to go
>>>> smaller and closer to the source system. This will take the form of
>>> native
>>>> code that builds upon the same efforts and items originally developed
>>> under
>>>> the Java ecosystem.
>>>> -
>>>>
>>>> Design should take consideration of disparate execution environments
>>>> and provide ways to robustly handle varying means of communication and
>>>> exchange. Accordingly, communications both in management of agents
>>> and the
>>>> transference of data should be neutral to technologies, providing the
>>> same
>>>> flexibility and adaptation that allows NiFi to communicate with a wide
>>>> breadth of systems, protocols, schemas, and formats.
>>>>
>>>>
>>>> [1]
>>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>>>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Matt Burgess <ma...@gmail.com>.
I'm a +1 as well.
> On Mar 11, 2016, at 8:26 AM, Tony Kurc <tr...@gmail.com> wrote:
>
> Should this be marked as a [VOTE]? In any case, I'm +1
>
>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
>>
>> All,
>>
>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
>> continuing on with the outlined procedure. If no one objects in the next
>> two days, will look at carrying out the prescribed items listed.
>>
>>
>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>
>>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>
>>> NiFi Community,
>>>
>>> Originally discussed in January [1], the MiNiFi agent model was met with
>>> positive feedback. I would like to propose a concerted effort toward the
>>> execution on the ideas presented and establish a basis for incorporation
>> of
>>> the feedback received from, and collaboration with, the community to move
>>> toward our goals of helping with dataflow from the point of its origin.
>>>
>>> To that end, I would like to propose the creation of:
>>>
>>> -
>>>
>>> a separate repository (nifi-minifi),
>>> -
>>>
>>> establishment of a MiNiFi JIRA (MINIFI), and
>>> -
>>>
>>> production of an associated feature proposals and design documentation
>>> within our Confluence Wiki spaces beyond the initial points outlined
>> by Joe
>>> with some additional proposals architecture and roadmap
>>>
>>> The separate JIRA and Git repo map to the existing ASF infrastructure for
>>> projects with similar efforts and will aid in a cleaner release and issue
>>> management process.
>>>
>>> Central to the aims of MiNiFi, the tenets of its operation and execution
>>> of dataflow are the same as NiFi itself: security, provenance, and
>>> management of dataflow; helping bring information to NiFi while
>> maintaining
>>> the full extent of its provenance.
>>>
>>> Some clarifying points based on the discussion that existed previously:
>>>
>>> -
>>>
>>> While there may be reuse of NiFi components and some overlap, MiNiFi
>>> is a separate effort that is complementary to but not necessarily
>> directly
>>> compatible with existing components and extensions. Obviously there
>> has
>>> been a lot of great effort which we can reuse, but in striving to be a
>>> smaller footprint, we should not find ourselves beholden to the
>> existing,
>>> core, NiFi architecture.
>>> -
>>>
>>> There will exist scenarios where there is an inherent need to go
>>> smaller and closer to the source system. This will take the form of
>> native
>>> code that builds upon the same efforts and items originally developed
>> under
>>> the Java ecosystem.
>>> -
>>>
>>> Design should take consideration of disparate execution environments
>>> and provide ways to robustly handle varying means of communication and
>>> exchange. Accordingly, communications both in management of agents
>> and the
>>> transference of data should be neutral to technologies, providing the
>> same
>>> flexibility and adaptation that allows NiFi to communicate with a wide
>>> breadth of systems, protocols, schemas, and formats.
>>>
>>>
>>> [1]
>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Tony Kurc <tr...@gmail.com>.
Should this be marked as a [VOTE]? In any case, I'm +1
On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri <al...@gmail.com> wrote:
> All,
>
> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
> continuing on with the outlined procedure. If no one objects in the next
> two days, will look at carrying out the prescribed items listed.
>
>
> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>
> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
>
> > NiFi Community,
> >
> > Originally discussed in January [1], the MiNiFi agent model was met with
> > positive feedback. I would like to propose a concerted effort toward the
> > execution on the ideas presented and establish a basis for incorporation
> of
> > the feedback received from, and collaboration with, the community to move
> > toward our goals of helping with dataflow from the point of its origin.
> >
> > To that end, I would like to propose the creation of:
> >
> > -
> >
> > a separate repository (nifi-minifi),
> > -
> >
> > establishment of a MiNiFi JIRA (MINIFI), and
> > -
> >
> > production of an associated feature proposals and design documentation
> > within our Confluence Wiki spaces beyond the initial points outlined
> by Joe
> > with some additional proposals architecture and roadmap
> >
> > The separate JIRA and Git repo map to the existing ASF infrastructure for
> > projects with similar efforts and will aid in a cleaner release and issue
> > management process.
> >
> > Central to the aims of MiNiFi, the tenets of its operation and execution
> > of dataflow are the same as NiFi itself: security, provenance, and
> > management of dataflow; helping bring information to NiFi while
> maintaining
> > the full extent of its provenance.
> >
> > Some clarifying points based on the discussion that existed previously:
> >
> > -
> >
> > While there may be reuse of NiFi components and some overlap, MiNiFi
> > is a separate effort that is complementary to but not necessarily
> directly
> > compatible with existing components and extensions. Obviously there
> has
> > been a lot of great effort which we can reuse, but in striving to be a
> > smaller footprint, we should not find ourselves beholden to the
> existing,
> > core, NiFi architecture.
> > -
> >
> > There will exist scenarios where there is an inherent need to go
> > smaller and closer to the source system. This will take the form of
> native
> > code that builds upon the same efforts and items originally developed
> under
> > the Java ecosystem.
> > -
> >
> > Design should take consideration of disparate execution environments
> > and provide ways to robustly handle varying means of communication and
> > exchange. Accordingly, communications both in management of agents
> and the
> > transference of data should be neutral to technologies, providing the
> same
> > flexibility and adaptation that allows NiFi to communicate with a wide
> > breadth of systems, protocols, schemas, and formats.
> >
> >
> > [1]
> >
> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
> >
>
Re: Establishment of MiNiFi repo and supporting tools
Posted by Aldrin Piri <al...@gmail.com>.
All,
Didn't explicitly mention this, but was aiming for a lazy consensus [1] to
continuing on with the outlined procedure. If no one objects in the next
two days, will look at carrying out the prescribed items listed.
[1] http://www.apache.org/foundation/voting.html#LazyConsensus
On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri <al...@gmail.com> wrote:
> NiFi Community,
>
> Originally discussed in January [1], the MiNiFi agent model was met with
> positive feedback. I would like to propose a concerted effort toward the
> execution on the ideas presented and establish a basis for incorporation of
> the feedback received from, and collaboration with, the community to move
> toward our goals of helping with dataflow from the point of its origin.
>
> To that end, I would like to propose the creation of:
>
> -
>
> a separate repository (nifi-minifi),
> -
>
> establishment of a MiNiFi JIRA (MINIFI), and
> -
>
> production of an associated feature proposals and design documentation
> within our Confluence Wiki spaces beyond the initial points outlined by Joe
> with some additional proposals architecture and roadmap
>
> The separate JIRA and Git repo map to the existing ASF infrastructure for
> projects with similar efforts and will aid in a cleaner release and issue
> management process.
>
> Central to the aims of MiNiFi, the tenets of its operation and execution
> of dataflow are the same as NiFi itself: security, provenance, and
> management of dataflow; helping bring information to NiFi while maintaining
> the full extent of its provenance.
>
> Some clarifying points based on the discussion that existed previously:
>
> -
>
> While there may be reuse of NiFi components and some overlap, MiNiFi
> is a separate effort that is complementary to but not necessarily directly
> compatible with existing components and extensions. Obviously there has
> been a lot of great effort which we can reuse, but in striving to be a
> smaller footprint, we should not find ourselves beholden to the existing,
> core, NiFi architecture.
> -
>
> There will exist scenarios where there is an inherent need to go
> smaller and closer to the source system. This will take the form of native
> code that builds upon the same efforts and items originally developed under
> the Java ecosystem.
> -
>
> Design should take consideration of disparate execution environments
> and provide ways to robustly handle varying means of communication and
> exchange. Accordingly, communications both in management of agents and the
> transference of data should be neutral to technologies, providing the same
> flexibility and adaptation that allows NiFi to communicate with a wide
> breadth of systems, protocols, schemas, and formats.
>
>
> [1]
> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html
>