.. Key points to consider: * Use RST format. For help with syntax refer http://sphinx-doc.org/rest.html * Use http://rst.ninjs.org/ a web based WYSIWYG RST editor. * For diagrams, you can use http://asciiflow.com to make ascii diagrams. * MUST READ http://docs.opendaylight.org/en/latest/documentation.html and follow guidelines. * Use same topic branch name for all patches related to this feature. * All sections should be retained, but can be marked None or N.A. * Set depth in ToC as per your doc requirements. Should be at least 2. .. contents:: Table of Contents :depth: 3 ===================== Title of the feature ===================== [link to gerrit patch] Brief introduction of the feature. Problem description =================== Detailed description of the problem being solved by this feature Use Cases --------- Use cases addressed by this feature. Proposed change =============== Details of the proposed change. Pipeline changes ---------------- Any changes to pipeline must be captured explicitly in this section. Yang changes ------------ This should detail any changes to yang models. Configuration impact --------------------- Any configuration parameters being added/deprecated for this feature? What will be defaults for these? How will it impact existing deployments? Note that outright deletion/modification of existing configuration is not allowed due to backward compatibility. They can only be deprecated and deleted in later release(s). Clustering considerations ------------------------- This should capture how clustering will be supported. This can include but not limited to use of CDTCL, EOS, Cluster Singleton etc. Other Infra considerations -------------------------- This should capture impact from/to different infra components like MDSAL Datastore, karaf, AAA etc. Security considerations ----------------------- Document any security related issues impacted by this feature. Scale and Performance Impact ---------------------------- What are the potential scale and performance impacts of this change? Does it help improve scale and performance or make it worse? Targeted Release ----------------- What release is this feature targeted for? Alternatives ------------ Alternatives considered and why they were not selected. Usage ===== How will end user use this feature? Primary focus here is how this feature will be used in an actual deployment. For most Genius features users will be other projects but this should still capture any user visible CLI/API etc. e.g. ITM configuration. This section will be primary input for Test and Documentation teams. Along with above this should also capture REST API and CLI. Features to Install ------------------- odl-genius-ui Identify existing karaf feature to which this change applies and/or new karaf features being introduced. These can be user facing features which are added to integration/distribution or internal features to be used by other projects. REST API -------- Sample JSONS/URIs. These will be an offshoot of yang changes. Capture these for User Guide, CSIT, etc. CLI --- Any CLI if being added. Implementation ============== Assignee(s) ----------- Who is implementing this feature? In case of multiple authors, designate a primary assignee and other contributors. Primary assignee: Other contributors: Work Items ---------- Break up work into individual items. This should be a checklist on Trello card for this feature. Give link to trello card or duplicate it. Dependencies ============ Any dependencies being added/removed? Dependencies here refers to internal [other ODL projects] as well as external [OVS, karaf, JDK etc.] This should also capture specific versions if any of these dependencies. e.g. OVS version, Linux kernel version, JDK etc. This should also capture impacts on existing project that depend on Genius. Following projects currently depend on Genius: * Netvirt * SFC Testing ======= Capture details of testing that will need to be added. Unit Tests ---------- Integration Tests ----------------- CSIT ---- Documentation Impact ==================== What is impact on documentation for this change? If documentation change is needed call out one of the who will work with Project Documentation Lead to get the changes done. Don't repeat details already discussed but do reference and call them out. References ========== Add any useful references. Some examples: * Links to Summit presentation, discussion etc. * Links to mail list discussions * Links to patches in other projects * Links to external documentation [1] `OpenDaylight Documentation Guide `__ [2] https://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html .. note:: This template was derived from [2], and has been modified to support our project. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode