|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| {{admon/warning|Draft Documents| HEY These are documents in a draft state did you notice!.}} | | {{admon/note|I have chosen to withdraw my participation in the ServerWG and Fedora.next and the proposals I had here on this page and ask everyone to respectfully use something else than what was written here on this page in their WG thanks...}} |
| | |
| = FedoraOS Server Platform ( FOSSP ) =
| |
| | |
| FedoraOS Server Platform ( FOSSP ) is an software architecture that serves as a foundation for server application, application stacks and server frameworks built on top of the FedoraOS ( FOS ), providing solid secure flexible and scalable server foundation with advanced control and manageability for more robust server environments.
| |
| | |
| FedoraOS Server Platform ( FOSSP ) consist of:
| |
| | |
| * GNU/Linux kernel to provide scalable operating system kernel.
| |
| * Dracut to provide an initramfs infrastructure.
| |
| * Systemd to provide service initialization, scalable system and network and container management and more.
| |
| * SELinux to provide mandatory access controls.
| |
| * BTRFS to provide filesystems with scalability,performance and security.
| |
| * DNF to provide Package Management
| |
| * Multipathd to provide input-output (I/O) fail-over and load-balancing for block devices.
| |
| * Bash to provide an command-line interface for interacting with the operating system.
| |
| * Util-Linux to provide a suite of essential tools and utilities.
| |
| * Openssh to provide secure remote access to the server
| |
| * NTP to provide networked clock synchronization.
| |
| * SSSD to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system.
| |
| * Augeas to provide local configuration API.
| |
| * Net-SNMP to provide monitoring of the health and welfare of the server and server applications.
| |
| * BareOS-client to provide secure efficient way to backup your server and application data.
| |
| | |
| = FedoraOS Server Platform ( FOSSP ) Installing, Updating and Upgrading =
| |
| | |
| == Installation overview ==
| |
| It is important that you create a deployment plan before you install FedoraOS Server Platform ( FOSSP ) and the related server role in your distributed environment yata yata.
| |
| | |
| == Installation methods ==
| |
| | |
| FedoraOS Server Platform ( FOSSP ) is made available with or without an predefined server role,ready to use ks for traditional method of installation,directly into an isolated or OS container or as an whole-disk images to be used in private/public cloud as instance-store image or standalone server in the cloud itself.
| |
| | |
| == Installation roadmap ==
| |
| Follow this roadmap to set up your FedoraOS Server Platform ( FOSSP ) and the related Server Role yata yata.
| |
| | |
| == Updates ==
| |
| Update policy TO-BE-DECIDED
| |
| | |
| == Upgrades ==
| |
| | |
| This section talks about some of the issues surrounding upgrades such as when and how systems administrators should deploy upgrades as well as methods for retrieving and performing updates.
| |
| | |
| FedoraOS Server Platform ( FOSSP ) provides *missing compatibility report ( fedup? )* that lets you know of anything you may have to address and outlines any necessary actions to take before ( or after? ) the upgrade process.
| |
| | |
| Upgrade Policy TO-BE-DECIDED
| |
| | |
| {{admon/warning|Draft Documents| Missing upgrade compatibility report ( fedup? )!!! o_O }}
| |
| | |
| == Restoring ==
| |
| | |
| If problems occur when you upgrade FedoraOS Server Platform ( FOSSP ) and the related Server Role tthis section describes how to revert/restore it to it's previous state yata yata.
| |
| | |
| = Stage Gate's Process =
| |
| | |
| Below write an stage gate proposal.
| |
| | |
| = Server Role Process Agreement =
| |
| | |
| Here we define how we determine each Server Role is created implemented and removed and that server roles requirement and which space it's intended to serve in the IT space.
| |
| | |
| = Server Role Application or Application Stack Selection Process =
| |
| | |
| The Server Roles application or application stack selection framework exists to establishes an environment in which the communities investments may consistently achieve successful outcomes that align with server's community goals and objectives.
| |
| | |
| The framework follows a stage gate review process, which is a phase-driven go/no-go decision point where the Server Working Groups activities are reviewed to
| |
| assure that appropriate application(s) and server role requirements are observed.
| |
| | |
| An application or application stack cannot proceed without a “go” decision by the Server Working Group and relevant partners for a specific stage gate.
| |
| | |
| Each Stage Gate Review is an independent confirmation by the Server Working Group Team (including any relevant critical partners) that all required application or application stacks reviews have been successfully conducted and met.
| |
| | |
| It checks that it has satisfactorily produced all the required deliverables and adequately met all exit criteria for a given application or application stack to permit advancement to the next phase.
| |
| | |
| The emphasis of the Stage Gate Review is on:
| |
| | |
| * The successful accomplishment of phase objectives.
| |
| * The plans for the next life cycle phase.
| |
| * The risks associated with moving into the next life cycle phase.
| |
| | |
| | |
| TODO Add picture of the Stage Gate Review Process
| |
| | |
| == Practice Overview ==
| |
| The Stage Gate Review is the evaluation process by which an application or application stack is authorized to progress from one life cycle phase to the next.
| |
| | |
| It is a collaborative practice in which all participants play an important role in assessing the server communities overall health and quality of execution to make an informed decision as to whether the application or application stack is ready to enter the next phase of its lifecycle and receive further resource commitments from the community.
| |
| | |
| This section summarizes a standardized approach to conducting a Stage Gate Review.
| |
| | |
| Given that each application or application stack as well as server role is different, the intent of each Stage Gate Review will slightly vary.
| |
| | |
| Regardless of what form the review takes, it must adhere to the approved level of application tailoring as defined in the Server Role Process Agreement deliverable.
| |
| | |
| Stage Gate Reviews have a common set of components which include:
| |
| | |
| Yata Yata must include more workflow picture
| |
| | |
| == Best Practices ==
| |
| | |
| The Server Working Group Stage Gate Review practice provides proven independent baseline review models.
| |
|
| |
| When implemented properly, the stage gate process accelerates the speed to market, increases the likelihood of success, reduces risk, and achieves
| |
| efficient and effective allocation of community resources.
| |
| | |
| Best practices include:
| |
| | |
| * Clearly defined roles and responsibilities:
| |
| | |
| Define roles and responsibilities so that participants are clear about expectations and the overall process.
| |
| | |
| * Server Working Group Gate Review preparation:
| |
| | |
| Prior to attending a Server Working Group Review meeting, all in attendance must have reviewed all pertinent documentation and have a good understanding of the project and its
| |
| performance, the context in which it is operating, and the exit criteria for the subject stage gate.
| |
| | |
| Members of the Server Working Group should also be familiar with any evaluation review forms/templates that will be used to document findings and support team decision processes.
| |
| | |
| * Server Working Group Gate Review coordination and facilitation:
| |
| | |
| A single individual should be responsible for planning, scheduling, organizing, and leading the Server Working Group Gate Review process.
| |
| | |
| By default this would be the FESCo liaison unless otherwise stated.
| |
| | |
| It is the responsibility of the Server Working Group Review Lead to make arrangements for the meeting and communicate with other participants.
| |
| | |
| Further, before the Server Working Group Gate Review meeting is concluded the lead should ensure that the Server Working Group Gate Review has achieved its purpose and
| |
| agreed upon next steps.
| |
| | |
| * Document, post, and share preliminary findings with the community:
| |
| | |
| Upon completion of the Server Working Groups Stage Gate Review meeting and prior to final submission of findings to the Server Community
| |
| | |
| Server Working Group Stage Gate Review findings should be shared with other participants as in application or application stack maintainer(s), Quality Assurance, Release Engineering and any other teams involvement, to ensure a mutual understanding of the results of the Stage Gate Review and next steps as it pertains to the governance cycle.
| |
| | |
| A clear and concise decision comes from the Server Working Group Stage Gate Review and it's outputs must be clearly documented and communicated.
| |
| | |
| Outputs include a decision (i.e.,approved, conditionally approved, or not approved) and a clear path forward.
| |
| | |
| A plan of action and milestones for corrective action if required should be defined along with a clear understanding of the oversight process that will be followed to ensure that the conditions are met.
| |
| | |
| == Practice Activities ==
| |
| Any given Stage Gate Review cycle should consist of the following activities:
| |
| | |
| The Server Working Group ensure that all deliverables are complete, accurate, and adequate to pass all mandatory exit criteria for the stage gate.
| |
| | |
| The Server Working Group Stage Gate Review Lead or his/her designated representative should formally document the team’s findings/recommendation and share a draft with the other participants as in application or application stack maintainer(s), Quality Assurance, Release Engineering and any other teams involvement to ensure a common understanding.
| |
| | |
| The Server Working Group Stage Gate Review Lead schedules a Stage Gate Review meeting with the Server Working Group Stage Gate Review Team (Critical Partners), including relevant critical partners, and collects/ distributes the appropriate documentation (e.g., inputs to the process) required for the review.
| |
| | |
| If the Server Working Group Stage Gate review finds too many outstanding issues, the Server Working Group Stage Gate Review Lead, at their discretion, may meet with the involved parties and request that deliverables be revised and/or resolved prior to the decision meeting, the outstanding issues.
| |
| | |
| The Server Working Group Stage Gate Review Lead should be clear in identifying the purpose of this particular review and identifying the subject project.
| |
| | |
| The Server Working Group Stage Gate Review Lead contacts the Server Community and interested partner or delegates that authority to alert them that a Stage Gate Review meeting has been scheduled and provides all relevant documentation prior to the meeting. Lead time for the meeting may vary based on the number of deliverables to be discussed and evaluated.
| |
| | |
| The Servers Working Group Stage Gate Review Team reviews the materials, completes their individual evaluations using provided templates and submits them to the Stage Gate Review Lead prior to the Stage Gate Review Meeting for compilation of the findings and observations.
| |
| | |
| The Server Working Group Stage Gate Review Team Lead distributes compiled findings back to the team.
| |
| | |
| The Server Working Group Stage Gate Review Lead contacts the Server Community and interested partner or delegates that authority to alert them that a Stage Gate Review meeting has been scheduled and provides all relevant documentation prior to the meeting. Lead time for the meeting may vary based on the number of deliverables to be discussed and evaluated.
| |
| | |
| This activity may continue until the Server Working Group Stage Gate Review Team, Business maintainer(s), Quality Assurance, Release Engineering and any other teams involvement are satisfied that significant issues are resolved.
| |
| | |
| The entire Server Working Group Stage Gate Review Team or just certain members may be involved with monitoring corrective action and approving completion to allow the application or application stack to advance to the next gate.
| |
| | |
| These requirements and associated process must be defined by the governing body (or its designated representative) at the point a Server Working Group Stage Gate Review decision is made.
| |
| All of the review materials should be stored in the projects library.
| |
| | |
| Stage Gate activities summarized above may vary depending on the degree of tailoring documented in the project’s approved Server Role Process Agreement.
| |
| | |
| == The Server Working Group Tasks and Review Process ==
| |
| | |
| The Server Working Group is responsible for but not limited to.
| |
| | |
| * Facilitates the Server Working Group Review meeting.
| |
| * Making arrangements for the working group meeting(s) and communicates the schedule with other participants as in application or application stack maintainer(s), Quality Assurance, Release Engineering and any other teams involvement.
| |
| * Collects/distribute the appropriate documentation to all parties involved.
| |
| * Ensure that each task has been completed and or achieved its purpose and agreed upon before proceeding to the next phase.
| |
| * Present the Working Group Review Team’s findings and a recommendation for the next step.
| |
| * Monitors corrective action and approving completion to allow the application or application stack to advance to phase.
| |
| | |
| = Stage Gate Review Points =
| |
| some design picture I guess here as well as re-usable template but i should go to sleep now...
| |
| | |
| == Initiation Phase ==
| |
| yata yata
| |
| | |
| == Concept Phase==
| |
| | |
| yata yata
| |
| | |
| == Planning Phase ==
| |
| | |
| yata yata
| |
| | |
| == Requirements Analysis Phase ==
| |
| | |
| yata yata
| |
| | |
| == Design And Marketing Phase ==
| |
| yata yata
| |
| | |
| == Development Phase ==
| |
| yata yata
| |
| | |
| == Testing Phase ==
| |
| | |
| yata yata
| |
| | |
| == Full Role Validation Phase ==
| |
| yata yata
| |
| | |
| == Launch/Availability would be here ==
| |
| | |
| Past launch stuff that stage gate approach does not think of by default
| |
| | |
| == Operations & Maintenance Phase ==
| |
| yata
| |
| | |
| == Application(s) Service Removal Phase ==
| |
| | |
| = Server Roles, Technologies and Features in FedoraOS Server Platform ( FOSSP ) =
| |
| | |
| This section provides a brief overview of the FedoraOS Server Platform ( FOSSP ) server roles and the general features that they provide.
| |
| | |
| Each server running FedoraOS Server Platform ( FOSSP ) runs one or more server roles.
| |
| A server role is a defined set of server application functionalities provided by that server.
| |
| You do not need to deploy all available server roles in your network but rather install only the server roles that contain the functionality that you want,require or need in your infrastructure.
| |
| | |
| Even if you are not familiar with all the server roles available in the FedoraOS Server Platform ( FOSSP ), the *Missing Infrastructure and or website Tool* can help identify and guide you to the best solution for the servers that you need to deploy, based on the features that you want,require or need in your infrastructure.
| |
| | |
| | |
| {{admon/warning|Draft Documents| *Missing Infrastructure and or website Tool*!!! o_O }}
| |
| | |
| === Application Services Server Role ===
| |
| Application Server Role enables you to create an integrated environment for deploying and running custom, server-based business applications.
| |
| | |
| * WildFly - links to PRD?
| |
| | |
| === Backup Services Server Role ===
| |
| Backup Services Server Role enables you to take and manage backup, recovery, and verification of computer data across a network of computers of different kinds.
| |
| | |
| * BareOS - links to PRD?
| |
| | |
| === Cloud Services Server Role ===
| |
| Cloud Services Server Role enables you to build private, public and hybrid cloud computing environments.
| |
| | |
| * Eucalyptus - links to PRD?
| |
| * Openstack - links to PRD?
| |
| | |
| === Container Services Server Role ===
| |
| | |
| The Container Server Role enables you to create a containerized server computing environment to improve the efficiency of your computing resources by utilizing more of your hardware resources.
| |
| | |
| * Docker - link to PRD?
| |
| * Libvirt-lxc - link to PRD?
| |
| * Systemd-nspawn - link to PRD?
| |
| | |
| === Database Services Server Role ===
| |
| Database Services Server Role enables you to run database management system in your infrastructure.
| |
| | |
| * MariaDB - links to PRD?
| |
| * PostgreSQL - links to PRD?
| |
| | |
| === Deployment Services Server Role ===
| |
| Deployment Services Server Role enables you to remotely deploy and update linux hosts over the network.
| |
| | |
| * Katello - links to PRD?
| |
| | |
| === Failover Clustering Services Server Role ===
| |
| Failover Clustering Services Server Role enables you to create a group of independent computers that work together to increase the availability of applications and services.
| |
| | |
| * Corosync - links to PRD?
| |
| | |
| === File and Storage Services Server Role ===
| |
| File and Storage Services Server Role enables you to create and manage network-attached storage file system.
| |
| | |
| * GlusterFS - links to PRD?
| |
| * iSCSI - links to PRD?
| |
| * NFSv4 - links to PRD?
| |
| | |
| === High Availability and Load Balancing Services Server Role ===
| |
| High Availability and Load Balancing Services Server Role enables you to load balances network traffic as well as adding additional servers as the load increases.
| |
| | |
| * HAProxy - links to PRD?
| |
| * LVS - links to PRD?
| |
| * Corosync - links to PRD?
| |
| | |
| === High Performance Services Server Role ===
| |
| High Performance Services Server Role enables you to run high-performance computing.
| |
| | |
| * I guess what OSGDC recommends and links to PRD?
| |
| | |
| === Lightweight Directory Services Server Role ===
| |
| Lightweight Directory Services Server Role enables you to provide flexible support for directory-enabled applications.
| |
| | |
| * 389ds - links to PRD?
| |
| * Samba4 AD - links to PRD?
| |
| | |
| === Media Streaming Services Server Role ===
| |
| Media Streaming Services Server Role enables you to stream live audio/video media content over networks.
| |
| | |
| * Flumotion - links to PRD?
| |
| * Erlyvideo - links to PRD?
| |
| | |
| === Network Services Server Role ===
| |
| | |
| Network Services Server Role enables you to deploy network services in your infrastructure.
| |
| | |
| * Tftp - links to PRD?
| |
| * ISC Bind - links to PRD?
| |
| * ISC DHCP - links to PRD?
| |
| | |
| === Telephony Services Server Role ===
| |
| Telephony Services Server Role enables you to telephony switching and private branch exchange service in your network.
| |
| | |
| * Asterisk - links to PRD?
| |
| | |
| === Virtualization Services Server Role ===
| |
| The virtualization Server Role enables you to create a virtualized server computing environment to improve the efficiency of your computing resources by utilizing more of your hardware resources.
| |
| | |
| * libvirt - link to PRD?
| |
| | |
| === Web Directory Services Server Role ===
| |
| Web Directory Services enables you to share information with users on the internal or internet.
| |
| | |
| * httpd - links to PRD?
| |
| * nginx - links to PRD?
| |
| | |
| = FedoraOS Server Platform ( FOSSP ) Support and Life cycle =
| |
| | |
| {{admon/warning|Draft Documents| We probably windup having to have FOS and FOSSP and each Server Role all on different release cycle o_O }}
| |
| | |
| FedoraOS Server Platform ( FOSSP ) life cycle phases are designed to reduce the level of change within each major release over time and make release availability and content more predictable for the actual length of the life cycle.
| |
| | |
| While we make every effort at maintaining quality, yata yata dont hesitate report that bug...
| |
| | |
| | |
| == name something level? ==
| |
| Release level maybe...
| |
| | |
| major release for all levels ( 1.0 --> 2.0 )== FOS/FOSSP/Server Role ( upgrades group + must reboot + cant downgrade )
| |
| | |
| New feature and enhancements are shipped in new releases for FOS, FOSSP and FOSSP Server Roles.
| |
| | |
| == Contents of new name something level? ==
| |
| afadf
| |
| | |
| == Service Packs ==
| |
| major minor releases ( 1.1 --> 1.2 ) == service packs ( updates preferred as a group support for individual kinda required )
| |
| | |
| == Contents of a Service Pack ==
| |
| Service packs contain fixes for:
| |
| | |
| * Security reported problems.
| |
| * Critical reported problems by administrators.
| |
| * Critical problems found by development or QA test teams.
| |
| | |
| Changes in services packs are limited to minimal corrections that do not change behaviour or
| |
| add new functionality to the current release.
| |
| | |
| There is nothing in the Service Pack that glues all the updates in a Service Pack together.
| |
| Most of the testing is done as a group so it's highly recommended that Service Pack is group updated however applying individual
| |
| updates per component is still available.
| |
| | |
| == Interim Fix ==
| |
| | |
| minor minor release ( 1.1.1 --> 1.1.2 ) == Interim Fix ( individual package updates )
| |
| | |
| Here you can find lists the FedoraOS Server Platform ( FOSSP ) lifecycle by release and the duration of support for that release.
| |
| | |
| | |
| {{admon/warning|Draft Documents| TODO figure out a proper release naming scheme for FOS and FOSSP and Server Role major and minor releases and change sample accordingly.
| |
| | |
| Propably name and the major, minornumber + their release date should work well enough however extending http://www.freedesktop.org/software/systemd/man/os-release.html might be needed. }}
| |
|
| |
|
| |
| {|
| |
| |-
| |
| ! FedoraOS Server Platform
| |
| ! Server Role
| |
| ! Server Role ID
| |
| ! Release
| |
| ! Release Date
| |
| ! Fixes Available Until ( EOL )
| |
| |-
| |
| | Application Services
| |
| | WildFly
| |
| | FOSSP-APSWI
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Backup Services
| |
| | Bacula
| |
| | FOSSP-BASBA
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Cloud Services
| |
| | Eucalyptus
| |
| | FOSSP-CLSEU
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Cloud Services
| |
| | Openstack
| |
| | FOSSP-CLSOS
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Container Services
| |
| | Docker
| |
| | FOSSP-CTSDO
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Container Services
| |
| | Libvirt-lxc
| |
| | FOSSP-CTSLI
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Container Services
| |
| | Systemd-nspawn
| |
| | FOSSP-CTSSN
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Database Services
| |
| | MariaDB
| |
| | FOSSP-DASMA
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Database Services
| |
| | PostgreSQL
| |
| | FOSSP-DASPO
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Deployment Services
| |
| | Katello
| |
| | FOSSP-DESKA
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Failover Clustering Services
| |
| | Corosync
| |
| | FOSSP-FCSCO
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | File and Storage Services
| |
| | GlusterFS
| |
| | FOSSP-FSSGF
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | File and Storage Services
| |
| | iSCSI
| |
| | FOSSP-FSSIS
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | File and Storage Services
| |
| | NFS
| |
| | FOSSP-FSSNF
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | High Availability and Load Balancing Services
| |
| | HAProxy
| |
| | FOSSP-HASHA
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | High Availability and Load Balancing Services
| |
| | LVS
| |
| | FOSSP-HASLV
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | High Availability and Load Balancing Services
| |
| | Corosync
| |
| | FOSSP-HASCO
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | High Performance Services
| |
| | OSGDC Stuff
| |
| | FOSSP-HPSOS
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Lightweight Directory Services
| |
| | 389ds
| |
| | FOSSP-LDS38
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Lightweight Directory Services
| |
| | Samba4 - AD
| |
| | FOSSP-LDSSA
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Media Streaming Services
| |
| | Flumotion
| |
| | FOSSP-MSSFL
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| | Media Streaming Services
| |
| | Erlyvideo
| |
| | FOSSP-MSSER
| |
| | 01-112615
| |
| | October 26 2015
| |
| | Not announced
| |
| |-
| |
| |}
| |
