@@ -1597,3 +1597,203 @@ detailed in subsections that follow.
1597
1597
For any {product-title} release, always review the instructions on
1598
1598
xref:../upgrading/index.adoc#install-config-upgrading-index[upgrading your cluster] properly.
1599
1599
====
1600
+
1601
+ [[ocp-3-9-27]]
1602
+ === RHBA-2018:1566 - {product-title} 3.9.27 Bug Fix and Enhancement Update
1603
+
1604
+ Issued: 2018-05-16
1605
+
1606
+ {product-title} release 3.9.27 is now available. The packages and bug fixes
1607
+ included in the update are documented in the
1608
+ link:https://access.redhat.com/errata/RHBA-2018:1566[RHBA-2018:1566] advisory.
1609
+ The container images included in the update are provided by the
1610
+ link:https://access.redhat.com/errata/RHBA-2018:1567[RHBA-2018:1567] advisory.
1611
+
1612
+ Space precluded documenting all of the bug fixes and images for this release in
1613
+ the advisory. See the following sections for notes on upgrading and details on
1614
+ the bug fixes and images included in this release.
1615
+
1616
+ [[ocp-3-9-27-upgrading]]
1617
+ ==== Upgrading
1618
+
1619
+ To upgrade an existing {product-title} 3.7 or 3.9 cluster to this latest
1620
+ release, use the automated upgrade playbook. See
1621
+ xref:../upgrading/automated_upgrades.adoc#running-the-upgrade-playbook-directly[Performing
1622
+ Automated In-place Cluster Upgrades] for instructions.
1623
+
1624
+ [[ocp-3-9-rhba-2018-1566-bug-fixes]]
1625
+ ==== Bug Fixes
1626
+
1627
+ * Build pods use multiple containers. Binary builds need to specify which
1628
+ container to stream content into, and for custom builds the name of the
1629
+ container is different from non-custom builds. When streaming binary content
1630
+ into a custom build, the expected container, git-clone, does not exist and the
1631
+ build fails. The logic for streaming binary content into a custom build pod will
1632
+ be changed to reference the correct container name, custom-build. With this bug
1633
+ fix, binary content will successfully stream into the custom build container.
1634
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1560659[*BZ#1560659*])
1635
+
1636
+ * Resource constraints can lead to the readiness probe in the example Jenkins
1637
+ templates readiness probes citing failure prematurely. Jenkins deployments would
1638
+ fail unnecessarily. With this bug fix, the readiness probe was relaxed in the
1639
+ templates. As a result, there is a decrease in unnecessary Jenkins deployment
1640
+ failures due to the aggressive readiness probe.
1641
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1559675[*BZ#1559675*])
1642
+
1643
+ * The master *_admin.kubeconfig_* file was added to the `oc command` to allow the
1644
+ operation to have the proper authorization and access to the necessary
1645
+ resources.
1646
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1561247[*BZ#1561247*])
1647
+
1648
+ * The installer improperly tried to set the SELinux context on a path that may not
1649
+ exist. This task was meant to work around a problem in CRI-O that no longer
1650
+ exists and, as such, that task has been removed.
1651
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1564949[*BZ#1564949*])
1652
+
1653
+ * Service catalog pods had a high log verbosity set by default. Therefore, service
1654
+ catalog pods on the master node produced a large amount of log data. The default
1655
+ log verbosity is now reset to a lower level.
1656
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1564179[*BZ#1564179*])
1657
+
1658
+ * The Elasticsearch server TLS certificate does not have an external host name in
1659
+ the subject alt. name list. Clients accessing Elasticsearch externally cannot
1660
+ turn on the MITM server certificate validation. When configuring Elasticsearch
1661
+ to allow external access, add the external host name in the subject alt. name
1662
+ list. TLS clients can turn on server certificate validation.
1663
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1554878[*BZ#1554878*])
1664
+
1665
+ * The Fluentd plug-in logs the entire error response on failure, which fills up
1666
+ the on-disk logs. The entire response is now only logged when in debug mode and
1667
+ on-disk logs no logger consume the disk.
1668
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1554885[*BZ#1554885*])
1669
+
1670
+ * The default write operation for Fluentd to Elasticsearch is `index`. Writes can
1671
+ trigger unnecessary `delete` operations for Elasticsearch, causing extra load
1672
+ that affects performance. Use the `create` operation. Writes to elasticsearch
1673
+ will only create records or skip updates if the records are duplicates reducing
1674
+ the load on the server.
1675
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1565909[*BZ#1565909*])
1676
+
1677
+ * The curator pod was crash-looping because it was unable to find its entry point
1678
+ script due to a bad merge from origin into downstream dist-git. The pod was not
1679
+ functional and cycled crash-looping. With this bug fix, the code was synced
1680
+ with upstream.
1681
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1572419[*BZ#1572419*])
1682
+
1683
+ * The Fluentd secure-forward plug-in supports the host name placeholder
1684
+ `${hostname}` in the configuration file. Although the value is case-sensitive,
1685
+ the upper case string `${HOSTNAME}` was set and it failed to pick up the correct
1686
+ hostname of the Fluentd container. The bug is now fixed.
1687
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1553576[*BZ#1553576*])
1688
+
1689
+ * After manually typing a URL with non-existing image, page load messaging would
1690
+ remain on the page, signaling that the page load is ongoing, even though it is
1691
+ done and the *The image stream details could not be loaded* alert is shown. Set
1692
+ the `loaded` scope variable when the image is or is not loaded and use it in the
1693
+ view to hide the *loading* messaging. After the attempt to load the image data,
1694
+ the *loading* messaging is now hidden, even if the image cannot be loaded.
1695
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1550797[*BZ#1550797*])
1696
+
1697
+ * Previously, the web console would not let you add new keys when editing a
1698
+ ConfigMap that was empty. Clicking *Add Item* in the editor would have no
1699
+ effect. With this bug fix, you can now correctly add items when editing a
1700
+ ConfigMap that has none.
1701
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1558863[*BZ#1558863*])
1702
+
1703
+ * Restricting DaemonSet nodes with the project's default node selector resulted in
1704
+ the deletion and creation of DaemonSet pods in a loop on those nodes that were
1705
+ restricted by adding project default node selector. With this bug fix, the
1706
+ upstream DaemonSet logic is now updated to be aware of the project's default
1707
+ node selector.
1708
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1571093[*BZ#1571093*])
1709
+
1710
+ * The Hawkular Alerts components has been removed from Hawkular Metrics. This
1711
+ change has no functional impact on Hawkular Metrics.
1712
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1543647[*BZ#1543647*])
1713
+
1714
+ * Previously there was incorrect management of OVS flows. If two nodes rebooted
1715
+ and swapped IP addresses when they came back up, then other nodes might not be
1716
+ able to send traffic to pods on one or both of those nodes. The code that
1717
+ manages OVS flows is now more careful to make the correct changes in cases of
1718
+ node IP reassignment. Pod-to-pod traffic should continue to work correctly even
1719
+ after nodes swap IP addresses.
1720
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1570394[*BZ#1570394*])
1721
+
1722
+ * The update Egress policy needed blocking outgoing traffic, patching OVS flows,
1723
+ and then re-enabling traffic. However, the OVS flow generation for DNS names was
1724
+ slow. This resulted in a few seconds of Egress traffic downtime, which may not
1725
+ be acceptable. With this bug fix, update Egress policy handling is updated to
1726
+ pre-populate all new OVS flows before blocking the outgoing traffic. This
1727
+ reduces the downtime during Egress policy updates.
1728
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1571430[*BZ#1571430*])
1729
+
1730
+ * When using per-namespace static egress IPs, all external traffic is routed
1731
+ through the egress IP. _External_ means all traffic, which is not directed to
1732
+ another pod, and so this includes traffic from the pod to the pod's node. When
1733
+ pods are told to use the node's IP address for DNS, and the pod is using a
1734
+ static egress IP, then DNS traffic will be routed to the egress node first, and
1735
+ then back to the original node, which might be configured to not accept DNS
1736
+ requests from other hosts, causing the pod to be unable to resolve DNS.
1737
+ Pod-to-node DNS requests now bypass the egress IP and go directly to the node
1738
+ and DNS works.
1739
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1570398[*BZ#1570398*])
1740
+
1741
+ * This bug fix addresses an issue on the node where setting disabling
1742
+ `cpu-cfs-quota` did not prevent CPU CFS limits from being set on pods when
1743
+ `cgroups-per-qos` was enabled.
1744
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1558155[*BZ#1558155*])
1745
+
1746
+ * This bug fix addresses an issue where clusters running with OpenStack cloud
1747
+ integration have nodes removed when the corresponding instance is stopped. Node
1748
+ resources whose instances are stopped are no longer removed from the cluster.
1749
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1558422[*BZ#1558422*])
1750
+
1751
+ * Nodes entered an impaired state when a volume is forcefully detached and not
1752
+ rebooted. Any new volume attached to the node is stuck in an attaching state.
1753
+ Any node that has a volume stuck in an attaching state for more than 21 minutes
1754
+ will be tainted and must be removed from cluster, then added back to remove the
1755
+ taint and fix the impaired state of the node. With this bug fix, impaired are
1756
+ removed from scheduling, giving the {product-title} administrator the ability to
1757
+ fix the node and bring it back.
1758
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1455680[*BZ#1455680*])
1759
+
1760
+ * Previous releases of {product-title} would improperly reconfigure `docker` to
1761
+ mark the internal registry as insecure when it should not have. This has been
1762
+ fixed in {product-title} 3.9 and should no longer happen.
1763
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1502028[*BZ#1502028*])
1764
+
1765
+ [[ocp-3-9-rhba-2018-1566-enhancements]]
1766
+ ==== Enhancements
1767
+
1768
+ * Use CRI-O as an RPM to use CRI-O as the container runtime. To install CRI-O as
1769
+ an RPM, set the following two options:
1770
+ +
1771
+ ----
1772
+ openshift_use_crio=True
1773
+ openshift_crio_use_rpm=True
1774
+ ----
1775
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1553186[*BZ#1553186*])
1776
+
1777
+ * The yedit module now generates unique backup files. Previously, if changes were
1778
+ made to the same resource multiple times, only the latest diff would be saved.
1779
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1555426[*BZ#1555426*])
1780
+
1781
+ * Administrators can now see messages for which we are unable to determine the
1782
+ proper namespace to associate with them. Otherwise, messages appear to be
1783
+ missing and are not viewable for review. A Kibana Index pattern will be created
1784
+ for administrators if it does not exist.
1785
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1519522[*BZ#1519522*])
1786
+
1787
+ * In the absence of inventory values, reuse the values used for the current
1788
+ deployment to preserve tuned values. In the case of Elasticsearch, when a user
1789
+ had done tuning of the cluster but did not propagate those values into
1790
+ variables, upgrading logging would use role default values, which may put the
1791
+ cluster in a bad state and lead to loss of log data. Values are now honored in
1792
+ order for EFK: inventory -> existing environment -> role defaults.
1793
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1561196[*BZ#1561196*])
1794
+
1795
+ * The number of Kibana index-patterns for cluster administrators is now limited.
1796
+ Previously, the list was unmanageable and unneeded on large clusters with many
1797
+ namespaces. Cluster administrators now only see a limited subset of
1798
+ index-patterns.
1799
+ (link:https://bugzilla.redhat.com/show_bug.cgi?id=1563230[*BZ#1563230*])
0 commit comments