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 <bbe...@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 <anilrain...@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 <anilrain...@gmail.com> wrote: > > > >> Thanks for the detailed explanation Bryan. > >> > >> Cheers > >> Anil > >> > >> > >> On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bbe...@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 <anilrain...@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 > >>> > >> > >> >
