NIFI-4678 also fixing a few asciidoc warnings

This commit is contained in:
joewitt 2017-12-14 17:09:12 -05:00
parent 68016ddbe8
commit 5b2e2afc17
2 changed files with 28 additions and 43 deletions

View File

@ -1158,23 +1158,17 @@ To allow User2 to move the GenerateFlowFile processor in the dataflow and only t
1. Select the GenerateFlowFile processor so that it is highlighted.
2. Select the Access Policies icon (image:iconAccessPolicies.png["Access Policies Icon"]) from the Operate palette and the Access Policies dialog opens.
3. Select “modify the component” from the policy drop-down.
image:processor-modify-policy.png["Processor Modify Policy"]
The “modify the component” policy that currently exists on the processor (child) is the “modify the component” policy inherited from the root process group (parent) on which User1 has privileges.
[start=4]
4. Select the Override link in the policy inheritance message. When creating the replacement policy, you are given a choice to override with a copy of the inherited policy or an empty policy.
image:override_policy_copy_empty.png["Create Override Policy"]
Select the Override button to create a copy.
[start=5]
5. On the replacement policy that is created, select the Add User icon (image:iconAddUser.png["Add User Icon"]). Find or enter User2 in the User Identity field and select OK.
image:processor-replacement-modify-policy.png["Processor Replacement Modify Policy"]
With these changes, User1 maintains the ability to move both processors on the canvas. User2 can now move the GenerateFlowFile processor but cannot move the LogAttribute processor.
image:user2-moved-processor.png["User2 Moved Processor"]
3. Select “modify the component” from the policy drop-down. The “modify the component” policy that currently exists on the processor (child) is the “modify the component” policy inherited from the root process group (parent) on which User1 has privileges.
+
image::processor-modify-policy.png["Processor Modify Policy"]
4. Select the Override link in the policy inheritance message. When creating the replacement policy, you are given a choice to override with a copy of the inherited policy or an empty policy. Select the Override button to create a copy.
+
image::override_policy_copy_empty.png["Create Override Policy"]
5. On the replacement policy that is created, select the Add User icon (image:iconAddUser.png["Add User Icon"]). Find or enter User2 in the User Identity field and select OK. With these changes, User1 maintains the ability to move both processors on the canvas. User2 can now move the GenerateFlowFile processor but cannot move the LogAttribute processor.
+
image::processor-replacement-modify-policy.png["Processor Replacement Modify Policy"]
+
image::user2-moved-processor.png["User2 Moved Processor"]
[[editing-a-processor]]
===== Editing a Processor
@ -1183,18 +1177,15 @@ In the “Moving a Processor” example above, User2 was added to the “modify
1. Select the GenerateFlowFile processor.
2. Select the Access Policies icon (image:iconAccessPolicies.png["Access Policies Icon"]) from the Operate palette and the Access Policies dialog opens.
3. Select "view the component” from the policy drop-down.
image:processor-view-policy.png["Processor View Policy"]
The view the component” policy that currently exists on the processor (child) is the "view the component” policy inherited from the root process group (parent) on which User1 has privileges.
[start=4]
3. Select "view the component” from the policy drop-down. The view the component” policy that currently exists on the processor (child) is the "view the component” policy inherited from the root process group (parent) on which User1 has privileges.
+
image::processor-view-policy.png["Processor View Policy"]
4. Select the Override link in the policy inheritance message, keep the default of Copy policy and select the Override button.
5. On the override policy that is created, select the Add User icon (image:iconAddUser.png["Add User Icon"]). Find or enter User2 in the User Identity field and select OK.
image:processor-replacement-view-policy.png["Processor Replacement View Policy"]
With these changes, User1 maintains the ability to view and edit the processors on the canvas. User2 can now view and edit the GenerateFlowFile processor.
image:user2-edit-processor.png["User2 Edit Processor"]
5. On the override policy that is created, select the Add User icon (image:iconAddUser.png["Add User Icon"]). Find or enter User2 in the User Identity field and select OK. With these changes, User1 maintains the ability to view and edit the processors on the canvas. User2 can now view and edit the GenerateFlowFile processor.
+
image::processor-replacement-view-policy.png["Processor Replacement View Policy"]
+
image::user2-edit-processor.png["User2 Edit Processor"]
[[creating-a-connection]]
===== Creating a Connection
@ -2383,7 +2374,7 @@ Before you begin, confirm that:
===== ZooKeeper Migration Steps
1. Collect the following information:
+
|====
|*Required Information*|*Description*
|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in <NiFi installation dir>/conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used.
@ -2392,15 +2383,14 @@ Before you begin, confirm that:
|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the <NiFi installation dir>/conf/zookeeper.properties. The port is specified in the *clientPort* property.
|Export data path|Determine the path that will store a json file containing the export of data from ZooKeeper. It must be readable and writable by the user running the zk-migrator tool.
|Source ZooKeeper Authentication Information|This information is in <NiFi installation dir>/conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument.
+
If the state-management.xml specifies Open, no authentication is required.
|Destination ZooKeeper Authentication Information|This information is in <NiFi installation dir>/conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument.
+
If the state-management.xml specifies Open, no authentication is required.
|Root path to which NiFi writes data in Source ZooKeeper (*sourceRootPath*)|This information can be found in <NiFi installation dir>/conf/state-management.xml under the Root Node property in the cluster-provider element. (default: /nifi)
|Root path to which NiFi writes data in Destination ZooKeeper (*destinationRootPath*)|This information can be found in <NiFi installation dir>/conf/state-management.xml under the Root Node property in the cluster-provider element.
|====
[start=2]
2. Stop all processors in the NiFi flow. If you are migrating between two NiFi installations, the flows on both must be stopped.
3. Export the NiFi component data from the source ZooKeeper. The following command reads from the specified ZooKeeper running on the given hostname:port, using the provided path to the data, and authenticates with ZooKeeper using the given username and password. The data read from ZooKeeper is written to the file provided.

View File

@ -461,12 +461,10 @@ To change a component version, perform the following steps.
1. Right-click the component on the canvas to display configuration options.
2. Select Change version.
+
image::processor-change-version.png["Processor Change Version"]
[start=3]
3. In the Component Version dialog, select the version you want to run from the Version drop-down menu.
+
image::component-version-dialog.png["Component Version"]
==== Understanding Version Dependencies
@ -890,12 +888,9 @@ image:process-group-controller-services-scope.png["Process Group Controller Serv
Use the following steps to add a Controller Service:
1. Click Configure, either from the Operate Palette, or from the Process Group context menu. This displays the process group Configuration window. The window has two tabs: General and Controller Services.
image:process-group-configuration-window.png["Process Group Configuration Window"]
The General tab is for settings that pertain to general information about the process group. For example, if configuring the root process group, the DFM can provide a unique name for the overall dataflow, as well as comments that describe the flow (Note: this information is visible to any other NiFi instance that connects remotely to this instance (using Remote Process Groups, a.k.a., Site-to-Site)).
[start=2]
1. Click Configure, either from the Operate Palette, or from the Process Group context menu. This displays the process group Configuration window. The window has two tabs: General and Controller Services. The General tab is for settings that pertain to general information about the process group. For example, if configuring the root process group, the DFM can provide a unique name for the overall dataflow, as well as comments that describe the flow (Note: this information is visible to any other NiFi instance that connects remotely to this instance (using Remote Process Groups, a.k.a., Site-to-Site)).
+
image::process-group-configuration-window.png["Process Group Configuration Window"]
2. From the Process Group Configuration page, select the Controller Services tab.
3. Click the Add button to display the Add Controller Service dialog.
4. Select the Controller Service desired, and click Add.