Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.10 Release Notes #9998

Merged
merged 1 commit into from
Jul 13, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 6 additions & 15 deletions dev_guide/topics/about_device_manager.adoc
Original file line number Diff line number Diff line change
@@ -1,27 +1,18 @@
== What Device Manager Does

[IMPORTANT]
====
Device Manager is a Technology Preview feature.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vikaschoudhary16 Can you please confirm that Device Manager is coming out of Tech Preview?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed with Jeremy that it's GA in 3.10

ifdef::openshift-enterprise[]
Technology Preview features are not supported with Red Hat production service
level agreements (SLAs), might not be functionally complete, and Red Hat does
not recommend to use them for production. These features provide early access to
upcoming product features, enabling customers to test functionality and provide
feedback during the development process.

For more information on Red Hat Technology Preview features support scope, see
https://access.redhat.com/support/offerings/techpreview/.
endif::[]
====

Device Manager is a Kubelet feature that provides a mechanism for advertising
specialized node hardware resources with the help of Kubelet plug-ins known as
xref:../dev_guide/device_plugins.adoc#using-device-plugins[device plug-ins].

Any vendor can implement a device plug-in to advertise their specialized
hardware without requiring any upstream code changes.

[IMPORTANT]
====
{product-title} supports the device plug-in API, but the device plug-in
containers are supported by individual vendors.
====

Device Manager advertises devices as *Extended Resources*. User pods can consume
devices, advertised by Device Manager, using the same *Limit/Request* mechanism,
which is used for requesting any other *Extended Resource*.
Expand Down
21 changes: 6 additions & 15 deletions dev_guide/topics/about_device_plugins.adoc
Original file line number Diff line number Diff line change
@@ -1,20 +1,5 @@
== What Device Plug-ins Do

[IMPORTANT]
====
Device Plug-ins are in Technology Preview and not for production workloads.
ifdef::openshift-enterprise[]
Technology Preview features are not supported with Red Hat production service
level agreements (SLAs), might not be functionally complete, and Red Hat does
not recommend to use them for production. These features provide early access to
upcoming product features, enabling customers to test functionality and provide
feedback during the development process.

For more information on Red Hat Technology Preview features support scope, see
https://access.redhat.com/support/offerings/techpreview/.
endif::[]
====

Device plug-ins allow you to use a particular device type (GPU, InfiniBand,
or other similar computing resources that require vendor-specific initialization
and setup) in your {product-title} pod without needing to write custom code. The
Expand All @@ -23,6 +8,12 @@ devices across clusters. The device plug-in provides support for these devices
through an extension mechanism, which makes these devices available to
containers, provides health checks of these devices, and securely shares them.

[IMPORTANT]
====
{product-title} supports the device plug-in API, but the device plug-in
containers are supported by individual vendors.
====

A device plug-in is a gRPC service running on the nodes (external to
`atomic-openshift-node.service`) that is responsible for managing specific
hardware resources. Any device plug-in must support following remote procedure
Expand Down
20 changes: 14 additions & 6 deletions install_config/persistent_storage/persistent_storage_csi.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,27 @@ toc::[]
Container Storage Interface (CSI) allows {product-title} to consume storage from storage backends that implement the link:https://github.com/container-storage-interface/spec[CSI interface] as xref:../../architecture/additional_concepts/storage.adoc#architecture-additional-concepts-storage[persistent
storage].


[NOTE]
[IMPORTANT]
====
CSI volumes is a beta feature and may change in a future release of {product-title}.
CSI volumes are currently in Technology Preview and not for production
workloads. CSI volumes may change in a future release of {product-title}.
ifdef::openshift-enterprise[]
Technology Preview features are not supported with
Red Hat production service level agreements (SLAs), might not be functionally
complete, and Red Hat does not recommend to use them for production. These
features provide early access to upcoming product features, enabling customers
to test functionality and provide feedback during the development process.

See the link:https://access.redhat.com/support/offerings/techpreview/[Red Hat
Technology Preview features support scope] for more information.
endif::[]
====


[NOTE]
====
{product-title} does not ship with any CSI drivers. It is recommended to use the CSI drivers provided by link:https://kubernetes-csi.github.io/docs/Drivers.html[community or storage vendors].
====

[NOTE]
====
{product-title} {product-version} supports version 0.2.0 of the link:https://github.com/container-storage-interface/spec[CSI specification].
====

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ toc::[]

[IMPORTANT]
====
Persistent volume (PV) provisionining using OpenStack Manila is a Technology Preview
Persistent volume (PV) provisioning using OpenStack Manila is a Technology Preview
feature only.
ifdef::openshift-enterprise[]
Technology Preview features are not supported with Red Hat production service
Expand All @@ -41,7 +41,7 @@ link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/[PVs],
link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[persistent
volume claims (PVCs)],
link:http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html[dynamic
provisioning], and
provisioning], and
link:https://kubernetes.io/docs/admin/authorization/rbac/[RBAC authorization] is recommended.

[[manilla-installation-setup]]
Expand Down
14 changes: 7 additions & 7 deletions release_notes/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
:experimental:

ifdef::openshift-enterprise[]
The following release notes for {product-title} 3.9 summarize all new features,
The following release notes for {product-title} 3.10 summarize all new features,
major corrections from the previous version, and any known bugs upon general
availability.
endif::[]
Expand All @@ -16,8 +16,8 @@ ifdef::openshift-dedicated[]
The following release notes for {product-title} summarize key features upon
general availability. OpenShift Dedicated uses the same code base as OpenShift
Container Platform 3; for more detailed technical notes, see the
link:https://docs.openshift.com/container-platform/3.9/release_notes/ocp_3_9_release_notes.html[OpenShift
Container Platform 3.9 Release Notes].
link:https://docs.openshift.com/container-platform/3.10/release_notes/ocp_3_10_release_notes.html[OpenShift
Container Platform 3.10 Release Notes].
endif::[]

[[release-versioning-policy]]
Expand All @@ -29,10 +29,10 @@ beta APIs (which may occasionally be changed in a non-backwards compatible
manner).

The {product-title} version must match between master and node hosts, excluding
temporary mismatches during cluster upgrades. For example, in a 3.9 cluster, all
masters must be 3.9 and all nodes must be 3.9. However, {product-title} will
continue to support older `oc` clients against newer servers. For example, a 3.4
`oc` will work against 3.3, 3.4, and 3.5 servers.
temporary mismatches during cluster upgrades. For example, in a 3.10 cluster, all
masters must be 3.10 and all nodes must be 3.10. However, {product-title} will
continue to support older `oc` clients against newer servers. For example, a 3.5
`oc` will work against 3.4, 3.5, and 3.6 servers.

Changes of APIs for non-security related reasons will involve, at minimum, two
minor releases (3.4 to 3.5 to 3.6, for example) to allow older `oc` to update.
Expand Down
Loading