tom

Added javadocs.

Renamed intent remove command.
...@@ -10,9 +10,9 @@ import org.onlab.onos.net.intent.IntentService; ...@@ -10,9 +10,9 @@ import org.onlab.onos.net.intent.IntentService;
10 /** 10 /**
11 * Removes host-to-host connectivity intent. 11 * Removes host-to-host connectivity intent.
12 */ 12 */
13 -@Command(scope = "onos", name = "remove-host-intent", 13 +@Command(scope = "onos", name = "remove-intent",
14 - description = "Removes host-to-host connectivity intent") 14 + description = "Removes the specified intent")
15 -public class RemoveHostToHostIntentCommand extends AbstractShellCommand { 15 +public class IntentRemoveCommand extends AbstractShellCommand {
16 16
17 @Argument(index = 0, name = "id", description = "Intent ID", 17 @Argument(index = 0, name = "id", description = "Intent ID",
18 required = true, multiValued = false) 18 required = true, multiValued = false)
......
...@@ -64,15 +64,15 @@ ...@@ -64,15 +64,15 @@
64 <action class="org.onlab.onos.cli.net.IntentsListCommand"/> 64 <action class="org.onlab.onos.cli.net.IntentsListCommand"/>
65 </command> 65 </command>
66 <command> 66 <command>
67 - <action class="org.onlab.onos.cli.net.AddHostToHostIntentCommand"/> 67 + <action class="org.onlab.onos.cli.net.IntentRemoveCommand"/>
68 <completers> 68 <completers>
69 - <ref component-id="hostIdCompleter"/> 69 + <ref component-id="intentIdCompleter"/>
70 </completers> 70 </completers>
71 </command> 71 </command>
72 <command> 72 <command>
73 - <action class="org.onlab.onos.cli.net.RemoveHostToHostIntentCommand"/> 73 + <action class="org.onlab.onos.cli.net.AddHostToHostIntentCommand"/>
74 <completers> 74 <completers>
75 - <ref component-id="intentIdCompleter"/> 75 + <ref component-id="hostIdCompleter"/>
76 </completers> 76 </completers>
77 </command> 77 </command>
78 78
......
...@@ -4,5 +4,53 @@ ...@@ -4,5 +4,53 @@
4 * <em>what</em> rather than the <em>how</em>. This makes such instructions 4 * <em>what</em> rather than the <em>how</em>. This makes such instructions
5 * largely independent of topology and device specifics, thus allowing them to 5 * largely independent of topology and device specifics, thus allowing them to
6 * survive topology mutations. 6 * survive topology mutations.
7 + * <p/>
8 + * The controller core provides a suite of built-in intents and their compilers
9 + * and installers. However, the intent framework is extensible in that it allows
10 + * additional intents and their compilers or installers to be added
11 + * dynamically at run-time. This allows others to enhance the initial arsenal of
12 + * connectivity and policy-based intents available in base controller software.
13 + * <p/>
14 + * The following diagram depicts the state transition diagram for each top-level intent:<br>
15 + * <img src="doc-files/intent-states.png" alt="ONOS intent states">
16 + * <p/>
17 + * The controller core accepts the intent specifications and translates them, via a
18 + * process referred to as intent compilation, to installable intents, which are
19 + * essentially actionable operations on the network environment.
20 + * These actions are carried out by intent installation process, which results
21 + * in some changes to the environment, e.g. tunnel links being provisioned,
22 + * flow rules being installed on the data-plane, optical lambdas being reserved.
23 + * <p/>
24 + * After an intent is submitted by an application, it will be sent immediately
25 + * (but asynchronously) into a compiling phase, then to installing phase and if
26 + * all goes according to plan into installed state. Once an application decides
27 + * it no longer wishes the intent to hold, it can withdraw it. This describes
28 + * the nominal flow. However, it may happen that some issue is encountered.
29 + * For example, an application may ask for an objective that is not currently
30 + * achievable, e.g. connectivity across to unconnected network segments.
31 + * If this is the case, the compiling phase may fail to produce a set of
32 + * installable intents and instead result in a failed compile. If this occurs,
33 + * only a change in the environment can trigger a transition back to the
34 + * compiling state.
35 + * <p/>
36 + * Similarly, an issue may be encountered during the installation phase in
37 + * which case the framework will attempt to recompile the intent to see if an
38 + * alternate approach is available. If so, the intent will be sent back to
39 + * installing phase. Otherwise, it will be parked in the failed state. Another
40 + * scenario that’s very likely to be encountered is where the intent is
41 + * successfully compiled and installed, but due to some topology event, such
42 + * as a downed or downgraded link, loss of throughput may occur or connectivity
43 + * may be lost altogether, thus impacting the viability of a previously
44 + * satisfied intent. If this occurs, the framework will attempt to recompile
45 + * the intent, and if an alternate approach is available, its installation
46 + * will be attempted. Otherwise, the original top-level intent will be parked
47 + * in the failed state.
48 + * <p/>
49 + * Please note that all *ing states, depicted in orange, are transitional and
50 + * are expected to last only a brief amount of time. The rest of the states
51 + * are parking states where the intent may spent some time; except for the
52 + * submitted state of course. There, the intent may pause, but only briefly,
53 + * while the system determines where to perform the compilation or while it
54 + * performs global recomputation/optimization across all prior intents.
7 */ 55 */
8 package org.onlab.onos.net.intent; 56 package org.onlab.onos.net.intent;
...\ No newline at end of file ...\ No newline at end of file
......