You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Sandeep Moré <mo...@gmail.com> on 2021/11/23 12:37:59 UTC
Re: Topology redeployment changes
Thanks Sandor!
I am also CC'ing the dev mailing list.
Thank you for the patch and the heads up :)
On Tue, Nov 23, 2021 at 4:12 AM Sandor Molnar <sm...@cloudera.com> wrote:
> Hi again!
>
> I just wanted to add some clarification on the above news. If you actually
> change the topology (adding a comment is not considered a change) and save
> it, Knox will continue to redeploy it w/o invoking the previously
> referenced KnoxCLI *redeploy* command. That command is needed only if you
> want to redeploy your topology without any change (to replace the
> well-known touch mechanism).
>
> Sandor
>
>
> On Tue, Nov 23, 2021 at 9:26 AM Sandor Molnar <sm...@cloudera.com>
> wrote:
>
>> Hi everyone!
>>
>> I've just merged a commit to fix
>> https://issues.apache.org/jira/browse/KNOX-2689. With my changes in
>> place, you will no longer be able to redeploy an XML-based topology by
>> simply touching it. Instead, you will have to run the following command:
>>
>> knoxcli.sh redeploy --cluster topologyName
>>
>> E.g. knoxcli.sh redeploy --cluster sandbox
>>
>> The related commit is merged into the master branch today that
>> corresponds to v2.0.0 (this version is not yet released). If you build the
>> project from the source and use it your own, please remember the
>> above-written changes.
>>
>> Cheers,
>> Sandor
>>
>
Re: Topology redeployment changes
Posted by Sandor Molnar <sm...@cloudera.com.INVALID>.
Thanks, Larry, for your comments.
I like the idea to make this new enhancement configurable and be backward
compatible with previous Knox versions. I filed this JIRA for tracking:
https://issues.apache.org/jira/browse/KNOX-2692
Sandor
On Tue, Nov 23, 2021 at 4:14 PM larry mccay <lm...@apache.org> wrote:
> This is an incompatible behavior change.
> I wonder whether we could make it configurable and an explicit opt-in
> behavior.
>
> I guess that the issue is that in certain deployments that a management
> application like Ambari may be writing out topologies based on a restart or
> config push even though there is no actual change.
> This change will reduce the outage for a topology while it is redeploying
> which is good.
>
> I guess the typical flow that would rely on this legacy behavior is a dev
> environment where you are working with rewrite rules or one of our Knox
> applications that we change locally and just need a redeploy.
> There may also be test environments that rely on it but not sure what their
> reliance on it would be where there is no actual change.
>
> If we are going to make this default behavior then we need to make sure it
> is listed as an incompatible change and not backported to the 1.6.x line.
>
> On Tue, Nov 23, 2021 at 7:38 AM Sandeep Moré <mo...@gmail.com>
> wrote:
>
> > Thanks Sandor!
> > I am also CC'ing the dev mailing list.
> >
> > Thank you for the patch and the heads up :)
> >
> > On Tue, Nov 23, 2021 at 4:12 AM Sandor Molnar <sm...@cloudera.com>
> > wrote:
> >
> >> Hi again!
> >>
> >> I just wanted to add some clarification on the above news. If you
> >> actually change the topology (adding a comment is not considered a
> change)
> >> and save it, Knox will continue to redeploy it w/o invoking the
> previously
> >> referenced KnoxCLI *redeploy* command. That command is needed only if
> >> you want to redeploy your topology without any change (to replace the
> >> well-known touch mechanism).
> >>
> >> Sandor
> >>
> >>
> >> On Tue, Nov 23, 2021 at 9:26 AM Sandor Molnar <sm...@cloudera.com>
> >> wrote:
> >>
> >>> Hi everyone!
> >>>
> >>> I've just merged a commit to fix
> >>> https://issues.apache.org/jira/browse/KNOX-2689. With my changes in
> >>> place, you will no longer be able to redeploy an XML-based topology by
> >>> simply touching it. Instead, you will have to run the following
> command:
> >>>
> >>> knoxcli.sh redeploy --cluster topologyName
> >>>
> >>> E.g. knoxcli.sh redeploy --cluster sandbox
> >>>
> >>> The related commit is merged into the master branch today that
> >>> corresponds to v2.0.0 (this version is not yet released). If you build
> the
> >>> project from the source and use it your own, please remember the
> >>> above-written changes.
> >>>
> >>> Cheers,
> >>> Sandor
> >>>
> >>
>
Re: Topology redeployment changes
Posted by larry mccay <lm...@apache.org>.
This is an incompatible behavior change.
I wonder whether we could make it configurable and an explicit opt-in
behavior.
I guess that the issue is that in certain deployments that a management
application like Ambari may be writing out topologies based on a restart or
config push even though there is no actual change.
This change will reduce the outage for a topology while it is redeploying
which is good.
I guess the typical flow that would rely on this legacy behavior is a dev
environment where you are working with rewrite rules or one of our Knox
applications that we change locally and just need a redeploy.
There may also be test environments that rely on it but not sure what their
reliance on it would be where there is no actual change.
If we are going to make this default behavior then we need to make sure it
is listed as an incompatible change and not backported to the 1.6.x line.
On Tue, Nov 23, 2021 at 7:38 AM Sandeep Moré <mo...@gmail.com> wrote:
> Thanks Sandor!
> I am also CC'ing the dev mailing list.
>
> Thank you for the patch and the heads up :)
>
> On Tue, Nov 23, 2021 at 4:12 AM Sandor Molnar <sm...@cloudera.com>
> wrote:
>
>> Hi again!
>>
>> I just wanted to add some clarification on the above news. If you
>> actually change the topology (adding a comment is not considered a change)
>> and save it, Knox will continue to redeploy it w/o invoking the previously
>> referenced KnoxCLI *redeploy* command. That command is needed only if
>> you want to redeploy your topology without any change (to replace the
>> well-known touch mechanism).
>>
>> Sandor
>>
>>
>> On Tue, Nov 23, 2021 at 9:26 AM Sandor Molnar <sm...@cloudera.com>
>> wrote:
>>
>>> Hi everyone!
>>>
>>> I've just merged a commit to fix
>>> https://issues.apache.org/jira/browse/KNOX-2689. With my changes in
>>> place, you will no longer be able to redeploy an XML-based topology by
>>> simply touching it. Instead, you will have to run the following command:
>>>
>>> knoxcli.sh redeploy --cluster topologyName
>>>
>>> E.g. knoxcli.sh redeploy --cluster sandbox
>>>
>>> The related commit is merged into the master branch today that
>>> corresponds to v2.0.0 (this version is not yet released). If you build the
>>> project from the source and use it your own, please remember the
>>> above-written changes.
>>>
>>> Cheers,
>>> Sandor
>>>
>>
Re: Topology redeployment changes
Posted by larry mccay <lm...@apache.org>.
This is an incompatible behavior change.
I wonder whether we could make it configurable and an explicit opt-in
behavior.
I guess that the issue is that in certain deployments that a management
application like Ambari may be writing out topologies based on a restart or
config push even though there is no actual change.
This change will reduce the outage for a topology while it is redeploying
which is good.
I guess the typical flow that would rely on this legacy behavior is a dev
environment where you are working with rewrite rules or one of our Knox
applications that we change locally and just need a redeploy.
There may also be test environments that rely on it but not sure what their
reliance on it would be where there is no actual change.
If we are going to make this default behavior then we need to make sure it
is listed as an incompatible change and not backported to the 1.6.x line.
On Tue, Nov 23, 2021 at 7:38 AM Sandeep Moré <mo...@gmail.com> wrote:
> Thanks Sandor!
> I am also CC'ing the dev mailing list.
>
> Thank you for the patch and the heads up :)
>
> On Tue, Nov 23, 2021 at 4:12 AM Sandor Molnar <sm...@cloudera.com>
> wrote:
>
>> Hi again!
>>
>> I just wanted to add some clarification on the above news. If you
>> actually change the topology (adding a comment is not considered a change)
>> and save it, Knox will continue to redeploy it w/o invoking the previously
>> referenced KnoxCLI *redeploy* command. That command is needed only if
>> you want to redeploy your topology without any change (to replace the
>> well-known touch mechanism).
>>
>> Sandor
>>
>>
>> On Tue, Nov 23, 2021 at 9:26 AM Sandor Molnar <sm...@cloudera.com>
>> wrote:
>>
>>> Hi everyone!
>>>
>>> I've just merged a commit to fix
>>> https://issues.apache.org/jira/browse/KNOX-2689. With my changes in
>>> place, you will no longer be able to redeploy an XML-based topology by
>>> simply touching it. Instead, you will have to run the following command:
>>>
>>> knoxcli.sh redeploy --cluster topologyName
>>>
>>> E.g. knoxcli.sh redeploy --cluster sandbox
>>>
>>> The related commit is merged into the master branch today that
>>> corresponds to v2.0.0 (this version is not yet released). If you build the
>>> project from the source and use it your own, please remember the
>>> above-written changes.
>>>
>>> Cheers,
>>> Sandor
>>>
>>