User and Policies

[Anil Rai <an...@gmail.com>]

All,

We noticed that we cannot add/modify users and policies when 1 node in a
cluster is down. So seems like all nodes should have the latest and
identical users.xml and auth*.xml. Is this correct? Shouldn't the latest
and up to date files be copied to other nodes during startup instead? (like
flow.gz)

Secondly, we configures groups, users and policies manually via the canvas.
Is there any automated way? and how do we propagate the users to other
environments?

Thanks
Anil

Re: User and Policies

[Anil Rai <an...@gmail.com>]

Thanks Bryan. It's just that the canvas looks very cluttered when we have a
lot of process groups. The fact that I cannot do anything with other
process groups, I was wondering if we can not shown them.


On Mon, May 14, 2018 at 4:31 PM, Bryan Bende <bb...@gmail.com> wrote:

> There intentionally isn't a way to hide components from the canvas.
> You can use the analogy of being in an apartment building and seeing
> all the doors... you can only see whats inside the one you have the
> key to, but you still know all the other locked doors are there.
>
>
> On Mon, May 14, 2018 at 4:10 PM, Anil Rai <an...@gmail.com> wrote:
> > On the same topic, we currently have many teams sharing our common
> > development environment. We have created groups for each team and added
> > users to the groups.
> > Each team is given a process group and this process group is assigned to
> > that specific group. So that they can only work on their process group
> and
> > do not mess with others.
> > It works fine.
> > Only problem on the canvas is that while I cannot mess with other process
> > groups, I still see other process groups in dotted lines and grayed out.
> Is
> > there a way to hide the other process groups from the canvas that I do
> not
> > have permissions to?
> >
> > Thanks
> > Anil
> >
> >
> >
> > On Mon, May 14, 2018 at 3:10 PM, Anil Rai <an...@gmail.com> wrote:
> >
> >> Thanks for the detailed explanation Bryan.
> >>
> >> Cheers
> >> Anil
> >>
> >>
> >> On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bb...@gmail.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> When a node joins the clusters, if the node has an empty flow.xml, no
> >>> users, and no authorizations, then the node will inherit all of those
> >>> from the cluster, but if any of those are populated then it won't be
> >>> able to join.
> >>>
> >>> One common issue that prevents this from working, is if you have an
> >>> initial admin populated on the new node, then it starts up and creates
> >>> the initial admin and policies locally, and when it attempts to join
> >>> the cluster it will not inherit because now technically it has a
> >>> user/policies defined which are in conflict with the cluster. So the
> >>> trick for a new node is to not fill in the initial admin in
> >>> authorizers.xml.
> >>>
> >>> Regarding creating users/groups/policies... anything you can do in the
> >>> UI can be done via the REST API, the best way to take a look is to
> >>> open Chrome Dev tools while you use the UI and checkout the calls made
> >>> in the network tab.
> >>>
> >>> You could write a script to perform any of these calls and automate
> >>> the creation.
> >>>
> >>> Thanks,
> >>>
> >>> Bryan
> >>>
> >>>
> >>> On Mon, May 14, 2018 at 2:22 PM, Anil Rai <an...@gmail.com>
> wrote:
> >>> > All,
> >>> >
> >>> > We noticed that we cannot add/modify users and policies when 1 node
> in a
> >>> > cluster is down. So seems like all nodes should have the latest and
> >>> > identical users.xml and auth*.xml. Is this correct? Shouldn't the
> latest
> >>> > and up to date files be copied to other nodes during startup instead?
> >>> (like
> >>> > flow.gz)
> >>> >
> >>> > Secondly, we configures groups, users and policies manually via the
> >>> canvas.
> >>> > Is there any automated way? and how do we propagate the users to
> other
> >>> > environments?
> >>> >
> >>> > Thanks
> >>> > Anil
> >>>
> >>
> >>
>

Re: User and Policies

[Bryan Bende <bb...@gmail.com>]

There intentionally isn't a way to hide components from the canvas.
You can use the analogy of being in an apartment building and seeing
all the doors... you can only see whats inside the one you have the
key to, but you still know all the other locked doors are there.


On Mon, May 14, 2018 at 4:10 PM, Anil Rai <an...@gmail.com> wrote:
> On the same topic, we currently have many teams sharing our common
> development environment. We have created groups for each team and added
> users to the groups.
> Each team is given a process group and this process group is assigned to
> that specific group. So that they can only work on their process group and
> do not mess with others.
> It works fine.
> Only problem on the canvas is that while I cannot mess with other process
> groups, I still see other process groups in dotted lines and grayed out. Is
> there a way to hide the other process groups from the canvas that I do not
> have permissions to?
>
> Thanks
> Anil
>
>
>
> On Mon, May 14, 2018 at 3:10 PM, Anil Rai <an...@gmail.com> wrote:
>
>> Thanks for the detailed explanation Bryan.
>>
>> Cheers
>> Anil
>>
>>
>> On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bb...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> When a node joins the clusters, if the node has an empty flow.xml, no
>>> users, and no authorizations, then the node will inherit all of those
>>> from the cluster, but if any of those are populated then it won't be
>>> able to join.
>>>
>>> One common issue that prevents this from working, is if you have an
>>> initial admin populated on the new node, then it starts up and creates
>>> the initial admin and policies locally, and when it attempts to join
>>> the cluster it will not inherit because now technically it has a
>>> user/policies defined which are in conflict with the cluster. So the
>>> trick for a new node is to not fill in the initial admin in
>>> authorizers.xml.
>>>
>>> Regarding creating users/groups/policies... anything you can do in the
>>> UI can be done via the REST API, the best way to take a look is to
>>> open Chrome Dev tools while you use the UI and checkout the calls made
>>> in the network tab.
>>>
>>> You could write a script to perform any of these calls and automate
>>> the creation.
>>>
>>> Thanks,
>>>
>>> Bryan
>>>
>>>
>>> On Mon, May 14, 2018 at 2:22 PM, Anil Rai <an...@gmail.com> wrote:
>>> > All,
>>> >
>>> > We noticed that we cannot add/modify users and policies when 1 node in a
>>> > cluster is down. So seems like all nodes should have the latest and
>>> > identical users.xml and auth*.xml. Is this correct? Shouldn't the latest
>>> > and up to date files be copied to other nodes during startup instead?
>>> (like
>>> > flow.gz)
>>> >
>>> > Secondly, we configures groups, users and policies manually via the
>>> canvas.
>>> > Is there any automated way? and how do we propagate the users to other
>>> > environments?
>>> >
>>> > Thanks
>>> > Anil
>>>
>>
>>

Re: User and Policies

[Anil Rai <an...@gmail.com>]

On the same topic, we currently have many teams sharing our common
development environment. We have created groups for each team and added
users to the groups.
Each team is given a process group and this process group is assigned to
that specific group. So that they can only work on their process group and
do not mess with others.
It works fine.
Only problem on the canvas is that while I cannot mess with other process
groups, I still see other process groups in dotted lines and grayed out. Is
there a way to hide the other process groups from the canvas that I do not
have permissions to?

Thanks
Anil



On Mon, May 14, 2018 at 3:10 PM, Anil Rai <an...@gmail.com> wrote:

> Thanks for the detailed explanation Bryan.
>
> Cheers
> Anil
>
>
> On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bb...@gmail.com> wrote:
>
>> Hello,
>>
>> When a node joins the clusters, if the node has an empty flow.xml, no
>> users, and no authorizations, then the node will inherit all of those
>> from the cluster, but if any of those are populated then it won't be
>> able to join.
>>
>> One common issue that prevents this from working, is if you have an
>> initial admin populated on the new node, then it starts up and creates
>> the initial admin and policies locally, and when it attempts to join
>> the cluster it will not inherit because now technically it has a
>> user/policies defined which are in conflict with the cluster. So the
>> trick for a new node is to not fill in the initial admin in
>> authorizers.xml.
>>
>> Regarding creating users/groups/policies... anything you can do in the
>> UI can be done via the REST API, the best way to take a look is to
>> open Chrome Dev tools while you use the UI and checkout the calls made
>> in the network tab.
>>
>> You could write a script to perform any of these calls and automate
>> the creation.
>>
>> Thanks,
>>
>> Bryan
>>
>>
>> On Mon, May 14, 2018 at 2:22 PM, Anil Rai <an...@gmail.com> wrote:
>> > All,
>> >
>> > We noticed that we cannot add/modify users and policies when 1 node in a
>> > cluster is down. So seems like all nodes should have the latest and
>> > identical users.xml and auth*.xml. Is this correct? Shouldn't the latest
>> > and up to date files be copied to other nodes during startup instead?
>> (like
>> > flow.gz)
>> >
>> > Secondly, we configures groups, users and policies manually via the
>> canvas.
>> > Is there any automated way? and how do we propagate the users to other
>> > environments?
>> >
>> > Thanks
>> > Anil
>>
>
>

Re: User and Policies

[Anil Rai <an...@gmail.com>]

Thanks for the detailed explanation Bryan.

Cheers
Anil


On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bb...@gmail.com> wrote:

> Hello,
>
> When a node joins the clusters, if the node has an empty flow.xml, no
> users, and no authorizations, then the node will inherit all of those
> from the cluster, but if any of those are populated then it won't be
> able to join.
>
> One common issue that prevents this from working, is if you have an
> initial admin populated on the new node, then it starts up and creates
> the initial admin and policies locally, and when it attempts to join
> the cluster it will not inherit because now technically it has a
> user/policies defined which are in conflict with the cluster. So the
> trick for a new node is to not fill in the initial admin in
> authorizers.xml.
>
> Regarding creating users/groups/policies... anything you can do in the
> UI can be done via the REST API, the best way to take a look is to
> open Chrome Dev tools while you use the UI and checkout the calls made
> in the network tab.
>
> You could write a script to perform any of these calls and automate
> the creation.
>
> Thanks,
>
> Bryan
>
>
> On Mon, May 14, 2018 at 2:22 PM, Anil Rai <an...@gmail.com> wrote:
> > All,
> >
> > We noticed that we cannot add/modify users and policies when 1 node in a
> > cluster is down. So seems like all nodes should have the latest and
> > identical users.xml and auth*.xml. Is this correct? Shouldn't the latest
> > and up to date files be copied to other nodes during startup instead?
> (like
> > flow.gz)
> >
> > Secondly, we configures groups, users and policies manually via the
> canvas.
> > Is there any automated way? and how do we propagate the users to other
> > environments?
> >
> > Thanks
> > Anil
>

Re: User and Policies

[Bryan Bende <bb...@gmail.com>]

Hello,

When a node joins the clusters, if the node has an empty flow.xml, no
users, and no authorizations, then the node will inherit all of those
from the cluster, but if any of those are populated then it won't be
able to join.

One common issue that prevents this from working, is if you have an
initial admin populated on the new node, then it starts up and creates
the initial admin and policies locally, and when it attempts to join
the cluster it will not inherit because now technically it has a
user/policies defined which are in conflict with the cluster. So the
trick for a new node is to not fill in the initial admin in
authorizers.xml.

Regarding creating users/groups/policies... anything you can do in the
UI can be done via the REST API, the best way to take a look is to
open Chrome Dev tools while you use the UI and checkout the calls made
in the network tab.

You could write a script to perform any of these calls and automate
the creation.

Thanks,

Bryan


On Mon, May 14, 2018 at 2:22 PM, Anil Rai <an...@gmail.com> wrote:
> All,
>
> We noticed that we cannot add/modify users and policies when 1 node in a
> cluster is down. So seems like all nodes should have the latest and
> identical users.xml and auth*.xml. Is this correct? Shouldn't the latest
> and up to date files be copied to other nodes during startup instead? (like
> flow.gz)
>
> Secondly, we configures groups, users and policies manually via the canvas.
> Is there any automated way? and how do we propagate the users to other
> environments?
>
> Thanks
> Anil