Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
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>
|
|
JIRA: GENESIS-42
Change-Id: I86fa60f39b97d33c6ba2c28ec952e85d6b826cf8
Signed-off-by: Weidong Shao <weidong.shao@huawei.com>
|
|
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>
|
|
|
|
|
|
default"
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
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>
|
|
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>
|
|
JIRA: GENESIS-25
Change-Id: I9d97df251e5942cfa4a77af85aa45631ec836325
Signed-off-by: Weidong Shao <weidong.shao@huawei.com>
|
|
JIRA: GENESIS-23
Change-Id: Ic39bef4daa6dc80a2c00bc0f0ddf9f26b46da333
Signed-off-by: Narinder Gupta <narinder.gupta@canonical.com>
|
|
Installers should supply a script or set of scripts ("deploy.sh") to automatically install the jumphost
(from there, the entire OPNFV system is automatically installed)
Change-Id: Ie564897469a152f11a91b07339972d5e8c50f284
JIRA: GENESIS-38
|
|
UX Requirement. Also fixes various line length issues
JIRA: GENESIS-16
Change-Id: I071a4571b922b526abc8325c430b4b933f08d3c5
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Slogan: Installers should support a common configuration file (e.g. kickstart file) per platform/role, so that the installed OS can be customized for hardware and role.
Change-Id: Ieab5adeb9938c99387527eeed3dfac1931890bf1
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Description: Hitless hardware upgrade: Increase size of a deployment in terms
of compute nodes (add additional compute nodes) without service interruption.
This requirement doesn't mandate upgrade/increasing the size of the control
node cluster.
JIRA: GENESIS-71
Change-Id: Ie716504ff58208394545e2ee47f347fb6dc3d53f
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
URL: https://jira.opnfv.org/browse/GENESIS-24
Description: Installers should install ssh keys on servers so that key-based
login can be used for administration
Change-Id: I7e04a09727f30c477332f870e43629943c4c0169
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
URL: https://jira.opnfv.org/browse/GENESIS-20
Description: Automatically populate discovered servers into install tool
(reduce user-intervention to a minimum).
Change-Id: I45d6291f5922ebfe81d7258943692b4786ee0326
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Change-Id: Iacd33bb2b41158931242efb24d7762261170f034
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
URL: https://jira.opnfv.org/browse/GENESIS-18
Description: Allow assignment of different roles to servers, so that
hardware and software can be configured according to the role.
Change-Id: I769391dc3e82492439141b0d9fd9fdf9c29c7bb6
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
URL: https://jira.opnfv.org/browse/GENESIS-12
Description: Add a new requirement (UX / Versioning):
Installers should track/control all versions of all components pulled
from external sources (user should be able to identify the versions
and origins of all software components deployed)
Change-Id: I39884c4b26e32800f145c1b8013491019521de48
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
URL: https://jira.opnfv.org/browse/GENESIS-9
Description: Add a requirement: The installer shall support the deployment
of OpenStack with High-Availability (for those components that support it
in Liberty) on 3 or more control nodes. Functest tests should be able to
verify that the HA is enabled and functional.
Change-Id: I56c5e905bb27c19b4b25e9cd796c03ec10b5caa3
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>
|
|
Base templates to articulate requirements which
are common and are to be followed by all installers
participating in Genesis. Template provided:
* Requirements for common system components
* Requirements for a common user experience
In additon, a high level directory structure is
put in place - to allow for later easy migration
of current BGS/Genesis common files.
Change-Id: I219246ee33eefe3a5b1cec421223d00745f0f910
Signed-off-by: Frank Brockners <fbrockne@cisco.com>
|