summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2016-02-15Apex - Genesis Requirements Matrix UpdateDan Radez1-30/+30
Change-Id: I2bfb268a6a9582d4c15d4a789dba43f488b655a7 Signed-off-by: Dan Radez <dradez@redhat.com>
2016-02-12Fuel Genesis Requirement complianceJonas Bjurel1-30/+30
Change-Id: I0f8be70bdbc98cc0480fd276030cd724258b6d6d Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2016-02-12Requirements support matrixFrank Brockners1-0/+88
Initial template for a document to capture which of the "common" features are supported by the different installers. Change-Id: Iebee29bca37168c39673453013e9333946f1315c Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-02-11Merge "License information update"Frank Brockners3-39/+9
2016-02-10License information updateFrank Brockners3-39/+9
OPNFV documentation is licensed under Creative Commons Attribution 4.0 International License. This patch updates the documents in the genesisreq repository to reflect license information appropriately. Change-Id: I54011bec422591853db8b3be99860c1b080cbccd Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-02-09Requirement update: OpenDaylight Be as defaultFrank Brockners1-1/+1
Installers should support the installation of OpenDaylight Beryllium release as default. OpenDaylight Beryllium became available in the form of stable release candidates during the final stages of the OPNFV Brahmaputra release composition. In was found that OpenDaylight Beryllium provides for several improvements over the Lithium release. This includes improved stability of tests as well as support for several projects (e.g. SFC, SDNVPN, etc.) All installers have successfully reported integration with OpenDaylight Beryllium. As a consequence, the original requirement for support of OpenDaylight Lithium was changed to support OpenDaylight Beryllium as default. JIRA: GENESIS-6 Change-Id: I4c09b2c4b30c7c45904fbc9b599cbaf2d43f3aa7 Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-02-09Merge "adding joid artificats for Ubuntu. Added the indivudual charm location."Frank Brockners1-3/+60
2016-02-07Merge "draft for common deploy file"Frank Brockners1-0/+35
2016-02-02adding joid artificats for Ubuntu. Added the indivudual charmNarinder Gupta1-3/+60
location. Change-Id: Ib3b48b7884f88505b89a83457cf98af853842280 Signed-off-by: Narinder Gupta <narinder.gupta@canonical.com>
2016-01-21Editorial updates to requirements docsFrank Brockners2-101/+92
Updates to system-requirements and ux-requirements docs. - Fixed formatting - Fixed broken links - Moved documentation requirements from system-req document to ux-req document - Fixed (some) grammar Note that non editorial fixes (e.g. removal for certain requirements no longer apply to Brahmaputra are handled in other patches). This patch is a replica of 7435 which got abandoned due to merge issues. Change-Id: Ibb914f523a7719f8240d4a690cd645f44500108e Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-01-21Merge "Removing NFV-KVM requirement for Brahmaputra"Frank Brockners1-1/+0
2016-01-20Removing SFC/OVS-NSH requirement for BrahmaputraFrank Brockners1-12/+0
Different than originally planned, the sfc project did not supply integration for all installers participating in Genesis. As a consequence, OVS-NSH (the specific version) cannot be supported as a common requirement for Brahmaputra. It will be reconsidered for Release 3. JIRA: GENESIS-46 Change-Id: I9e9968f5c1da12c6620794cc8c4ff4c9293792bd Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-01-20Removing NFV-KVM requirement for BrahmaputraFrank Brockners1-1/+0
Different than originally planned, the nfv4kvm project did not supply integration for all installers participating in Genesis. As a consequence, NFV-KVM cannot be supported as a common requirement for Brahmaputra. It will be reconsidered for Release 3. JIRA: GENESIS-50 Change-Id: I3de736e12ee37e23ba0de524283804ac3d33d0ff Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-01-17Key artifacts and their locationFrank Brockners1-0/+52
For Brahmaputra, we're using an "all in one" build approach. There is no need for a specific configuration file that installers would use as part of their build process which points to the location of components that will be included. The "artifacts-location" file is to serve documentation purposes only for the Brahmaputra release. It is to list all key artifacts and their location. This patch creates the starting point for the documentation. This patch is a replica of 4585 which was abandoned due to merge/rebase issues. Change-Id: I09dba4686d908cf25edf2ff9a4de054959e035a1 Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2016-01-14draft for common deploy fileDan Radez1-0/+35
Change-Id: I13b3b39f9105bedd6a6ea96d97978dee6f832dcb Signed-off-by: Dan Radez <dradez@redhat.com> Signed-off-by: Tim Rozet <trozet@redhat.com>
2016-01-04Requirement: OpenStack Heat installed (for QTIP)Frank Brockners1-0/+5
The OPNFV Qtip project requires the installation of Openstack Heat. Replica patch of 4435, which was abandoned due to merge/rebase issues. JIRA: GENESIS-53 Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2015-12-23Merge "Requirement: SDN Controller Layer 3 forwarding support"Tim Rozet1-0/+2
2015-12-23Merge "Common inventory file format example"Tim Rozet1-0/+13
2015-12-18Merge "Requirement: "All-in-one" build for Brahmaputra"Frank Brockners1-0/+11
2015-12-16Hardware replacementWei Shao1-0/+1
It must be possible to de-comision and re-commision hardware to an existing OPNFV deployment. This is among other things needed when replacing faulty hardware. JIRA: GENESIS-40 Change-Id: Ieeec061de5f315fcb00e73d66bfaa3fd0a49e118 Signed-off-by: Wei Shao <weidong.shao@huawei.com>
2015-12-16Merge "Add GENESIS-42 for support of offline deployment"Weidong Shao1-0/+4
2015-12-16Merge "Requirement: Provide isolated compute node resources for CEPH OSD"Wei Shao1-0/+3
2015-12-15Common inventory file format exampleTim Rozet1-0/+13
Format of pod settings to input into every installer. Change-Id: Iee898ee7c1d6e0a34310f1fc28f8dd5da7e0a070 Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-12-09Requirement: "All-in-one" build for BrahmaputraFrank Brockners1-0/+11
Installers which create a build for Brahmaputra, should create the build as an "all-in-one" build. The the build process of the installer creates a single entity (e.g. ISO) - which has all the artifacts considered and required by all the projects for Brahmaputra packaged in. Or in other terms and as an example: If there are 4 different versions of OVS - all these 4 versions would be contained in the "all in one build". Note: This requirement only applies to installers which support a "build" phase (i.e. create a bootable image, like an iso-image from the different artifacts required). JIRA: GENESIS-74 Change-Id: Ia6f126ae8a062c8e3158b65835a9ae2429cba321 Signed-off-by: Frank Brockners <fbrockne@cisco.com>
2015-12-07Requirement: SDN Controller Layer 3 forwarding supportTim Rozet1-0/+2
This is a proposal to require Installers to support the ability to enable L3 routing functionality in the SDN Controller (where possible). Some SDN controllers may not support this functionality, in which case it is acceptable to use Neutron L3 agent. OpenDaylight also supports distributed virtual routing (DVR). This requirement also proposes that Installers should be capable of enabling DVR on SDN controllers which support DVR. JIRA: GENESIS-44 Change-Id: Ib0e585f05cc75d30b198863bba342e2062ca255e Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-12-07Merge "Requirement: Ability to install with upstream artifacts"Tim Rozet1-5/+2
2015-12-07Merge "Requirement: Installers to be agnostic to type of hard drives used"Tim Rozet1-4/+2
2015-12-07Merge "User-configurable parameters available via config files"Tim Rozet1-0/+2
2015-12-07Requirement: Supported Layer 1/2 Networking ConfigurationsTim Rozet1-0/+3
Installers should support multiple kinds of network configurations for deployments. These shall include the following: 1) Multiple VLANs (untagged and tagged links) 2) NIC Bonding/Etherchannel 3) Multiple NICs These types may also be in combination with one another. For example, if a deployment uses 4 logical broadcast domains (VLANs) it may be split into 4 sub-interfaces on a single interface, which is then mapped to a bonded link consisting of 2 links. JIRA: GENESIS-61 Change-Id: Id30cfe1c01c3b82d94aaf454d6496180c29732e9 Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-12-07Requirement: Supported Logical Networks for Target SystemTim Rozet1-0/+3
Installers must support being able to separate network traffic for OpenStack + SDN controllers into these logical networks: 1) Admin network - used by OpenStack for Admin user traffic 2) Private network- used by OpenStack for inter-component traffic 3) Public network- user + internet access. References OpenStack public network. 4) Storage network - for storage related traffic only OpenStack is configurable in that it allows its components to be bound to specific networks. Installers should also support configuring OpenStack this way, and separating components/traffic across these logical networks. For example, keystone admin endpoint should only be available on the Admin network. Access to keystone admin endpoint on Public network would not be allowed. Note: This requirement does not restrict installers from deploying other types of logical network configurations such as combining all traffic into a single logical network, or combining some logical networks into one. The requirement simply states that the 4 listed above must be supported and the default option. An optional 5th network for lights out management (IPMI access) is also typically used (especially with baremetal deployments), but it is beyond the scope of this requirement (logical OpenStack networks), and it's network definition/configuration should be defined by the environment/POD being used. JIRA: GENESIS-62 Change-Id: I3942bba91f0831a1f8088fa75968d23aa968eebe Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-12-07Add GENESIS-42 for support of offline deploymentWeidong Shao1-0/+4
JIRA: GENESIS-42 Change-Id: I86fa60f39b97d33c6ba2c28ec952e85d6b826cf8 Signed-off-by: Weidong Shao <weidong.shao@huawei.com>
2015-12-07Merge "Instaler should provide user guide and release notes."Weidong Shao1-0/+11
2015-12-07Requirement: Installers to be agnostic to type of hard drives usedTim Rozet1-4/+2
Installer should be agnostic to the type of hard-drive the servers boot from (spinning disks, SSD, …) as long as those types are supported by drivers found in the supported linux versions for B release. JIRA: GENESIS-31 Change-Id: Ib1e224aedaf63f1606b6e9a22a859fb0e5e09825 Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-12-07Merge "nfv-kvm installation requirement"Wei Shao1-0/+1
2015-12-07Merge "Support L3-neutron agent as an option for L3"Wei Shao1-0/+3
2015-12-07Instaler should provide user guide and release notes.Weidong Shao1-0/+11
JIRA: GENESIS-34 JIRA: GENESIS-35 Change-Id: Ie43b76b5eb852d6731f9d5bb6f20795020baa6bc Signed-off-by: Weidong Shao <weidong.shao@huawei.com>
2015-12-02Merge "Added JIRA GENESIS-38 Requirement: Script to install jumphost"Frank Brockners1-0/+2
2015-12-02Merge "Added Jira requirement GENESIS-23 Enable Mandatory Access Control by ↵Frank Brockners1-1/+1
default"
2015-12-02Added JIRA: GENESIS-46 for votingJonas Bjurel1-0/+11
Description: The SFC project needs a version of OVS that supports Network Service Headers (NSH). The required end-system state for the B-release will be an official OVS patch that Intel is preparing that will provide full OVS 2.4 support. This official OVS patch is not available yet. Until this official patch is available, there is a patch available in a private branch that we will have to use during the life cycle of the B release. This private OVS branch does not support all of the OVS 2.4 features. The private OVS branch can be obtained as follows: git clone -b nsh-v8 https://github.com/priteshk/ovs.git JIRA:GENESIS-46 Change-Id: Iae5a102340ba5b7a75651c7efb9256566177ed8d Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
2015-12-01Requirement: Provide isolated compute node resources for CEPH OSDWei Shao1-0/+3
Installers should provide for having Compute nodes taking part as Ceph storage nodes (OSD), and reliably provide isolated resources for this role JIRA: GENESIS-69 Change-Id: Ia7669983c99eb7bcf5646b57d62fd12bd143d370 Signed-off-by: Wei Shao <weidong.shao@huawei.com>
2015-12-01nfv-kvm installation requirementWei Shao1-0/+1
Project Name: (nfv-kvm)(NFV Hypervisors-KVM) Project Lead: Don Dugger (donald.d.dugger@intel.com) Target Release: B release List of proposed requirements: 1) Install Kernel package with NFV enhancement support 2) Install QEMU package with NFV enhancement support 3) Provide a method so that user can input platform specific parameters. OPNFV release: Brahmaputra Timeline: In order to integrate into CI and fix bugs we would require implementation at least 2 months prior to B-release Purpose: Special kernel/QEMU functions may be needed to meet advanced NFV usage requirements, like real time, live migration etc. The nfv4kvm project provide such functionality, so it will be good to integrate the kernel/QEMU into the installer. Proposed requirements: 1) Nfv-kvm would provide kernel source and QEMU source that meet NFV requirement, including real time, live migration etc. The installer can install the kernel/qemu package build from the kernel/qemu repo code. 2) Grub entry would be updated to adding NFV specific kernel parameters like "isolcpus", "nohz_full" etc. The installer should get input from user for such parameters. JIRA: GENESIS-50 Change-Id: Ifb52d1bfeb60c79cbb51c9c6d16da204f652f467 Signed-off-by: Wei Shao <weidong.shao@huawei.com>
2015-12-01Support L3-neutron agent as an option for L3Wei Shao1-0/+3
Because ODL Lithium doesn't support IPv6 in ODL-L3, in order to set up IPv6 in integrated OS+ODL environment, we need to use neutron-l3-agent instead of odl-l3, and ODL will be used only for L2 connectivity. See our gap analysis https://wiki.opnfv.org/ipv6_opnfv_project/ipv6_gap_odl. Therefore we have created this JIRA issue "Support L3-neutron agent as an option for L3 for setting up". JIRA: GENESIS-72 Change-Id: I86d7cdf6b8a802a5766f57fe33e9c8b4b7916b78 Signed-off-by: Wei Shao <weidong.shao@huawei.com>
2015-12-01Merge "Installer should configure NTP server for clock synchronization."Weidong Shao1-1/+3
2015-11-30Requirement: Ability to install with upstream artifactsTim Rozet1-5/+2
Installers should support deployment of OPNFV using artifacts (source code, packages, etc) from 3rd-party repos (vendor specific distros and trunk versions). For example, if an OPNFV project required a specific version of OVS (and provided the compatible artifact) to be installed, an installer would be able to point directly to that artifact and build/deploy with it. JIRA: GENESIS-39 Change-Id: Iea8eddf36b03c124f7fb048f4c301179b2697b59 Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-11-30User-configurable parameters available via config filesTim Rozet1-0/+2
User-configurable parameters available via config.yaml files - with all defaults shown. Exact parameters and formats for these configuration files are outside the scope of this requirement (and TBD by Genesis team). The requirement is simply to be able to support parsing these yaml config files as inputs to all installers. JIRA: GENESIS-17 Change-Id: Id484d59205ce6b423329cfa0a86b7d6d22c04dba Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-11-30Merge "Requirement: Neutron DHCP servers in HA"Tim Rozet1-9/+7
2015-11-18Requirement: Neutron DHCP servers in HATim Rozet1-9/+7
We currently have most openstack services in HA, including neutron-dhcp-agent service. Meaning that there are multiple neutron-dhcp-agent processes running on the controllers. One of those is selected when there is a request to create a dhcp server namespace. A single dhcp server will be created for that tenant. This issue is created as a proposal for requiring OPNFV Target System to enable multiple dhcp servers per tenant in HA, so that a tenant would have multiple dhcp servers in HA in case one goes down. JIRA: GENESIS-43 Change-Id: I1386c790834c0924ec90eb505d14ca7c8449f408 Signed-off-by: Tim Rozet <trozet@redhat.com>
2015-11-18Merge "Requirement proposal: Support for ONOSFW"Weidong Shao1-0/+4
2015-11-16Installer should configure NTP server for clock synchronization.Weidong Shao1-1/+3
JIRA: GENESIS-25 Change-Id: I9d97df251e5942cfa4a77af85aa45631ec836325 Signed-off-by: Weidong Shao <weidong.shao@huawei.com>
2015-11-11Added Jira requirement GENESIS-23 Enable Mandatory Access Control by defaultNarinder Gupta1-1/+1
JIRA: GENESIS-23 Change-Id: Ic39bef4daa6dc80a2c00bc0f0ddf9f26b46da333 Signed-off-by: Narinder Gupta <narinder.gupta@canonical.com>