-
Notifications
You must be signed in to change notification settings - Fork 2
Expand file tree
/
Copy pathrelease.html.md.erb
More file actions
executable file
·129 lines (85 loc) · 8.2 KB
/
release.html.md.erb
File metadata and controls
executable file
·129 lines (85 loc) · 8.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
---
title: Release Notes
owner: Metrix
---
## <a id="latest"></a> 1.0.11
**Release Date: April 28, 2017**
### Notes
* Updates the stemcell version required to v3363.20
### Known Issues
* During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs
are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately
no workaround at this stage.

* Disabling the "Enable Shard Allocation" errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the "Enable Shard Allocation" errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a "broken" state; specifically it will be unable to create new daily indexes at midnight UTC.
<br><br>
If you suspect this has happened, check whether your cluster's `cluster.routing.allocation.enable` setting has been set to something other than `all` by querying: `http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty`. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.
## <a id="latest"></a> 1.0.10
**Release Date: April 20, 2017**
### Notes
* Updates the stemcell version required to v3363.15
### Known Issues
* If use of stemcell v3363.19 or later is desired, please use Log Search v1.0.11, as v1.0.10 began experiencing build issues beginning in v3363.19. Patch v1.0.11 resolves for stemcell v3363.19 and later.
* During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs
are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately
no workaround at this stage.

* Disabling the "Enable Shard Allocation" errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the "Enable Shard Allocation" errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a "broken" state; specifically it will be unable to create new daily indexes at midnight UTC.
<br><br>
If you suspect this has happened, check whether your cluster's `cluster.routing.allocation.enable` setting has been set to something other than `all` by querying: `http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty`. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.
## <a id="latest"></a> 1.0.4
**Release Date: November 23, 2016**
### Notes
* Updates the stemcell version required to v3263
* Updates the OpenJDK version to v1.8.0.111
* Updates the golang version to v1.7.3
### Known Issues
* During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs
are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately
no workaround at this stage.

* Disabling the "Enable Shard Allocation" errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the "Enable Shard Allocation" errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a "broken" state; specifically it will be unable to create new daily indexes at midnight UTC.
<br><br>
If you suspect this has happened, check whether your cluster's `cluster.routing.allocation.enable` setting has been set to something other than `all` by querying: `http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty`. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.
## <a id="latest"></a> 1.0.2
**Release Date: November 14, 2016**
### Notes
#### Enhancements
* Updates all components to latest minor versions.
* Uses a lower privilege `logsearch-firehose` user to access the Elastic Runtime Firehose.
<p class="note"><strong>Note</strong>: This change to the firehose user raises the minimum Elastic Runtime version requirement to 1.7.16 or later</p>
* Ingests platform metrics by default from the Elastic Runtime Firehose. You can also configure Log Search to ingest application logs and metrics. See the [Consume App Logs from the Elastic Runtime Firehose](installing.html#firehose) section of the install topic.
* Labels `Enable shard allocation` errand as required
#### Bug Fixes
* Prevents running with more than 1 Elasticsearch master VM.
* Allows running with multiple ingestor VMs.
* `ValueMetrics` and `CounterEvents` consumed from the Firehose contain the correct `@source` information.
### Known Issues
* During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs
are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately
no workaround at this stage.

* Disabling the "Enable Shard Allocation" errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the "Enable Shard Allocation" errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a "broken" state; specifically it will be unable to create new daily indexes at midnight UTC.
<br><br>
If you suspect this has happened, check whether your cluster's `cluster.routing.allocation.enable` setting has been set to something other than `all` by querying: `http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty`. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.
## <a id="1.0.1"></a> 1.0.1
**Release Date: October 07, 2016**
### Known Issues
* See known issues listed for 1.0.0
### Notes
* PCF Log Search 1.0.1 - stemcell change to support upgrades to the 4.4 kernel.
## <a id="1.0.0"></a> 1.0.0
**Release Date: June 2016**
### Known Issues
* During a stemcell upgrade there will be 2 x ~2 min (time it takes your IaaS to create new VM) intervals where logs
are NOT ingested. This happens when the singleton Queue and Router nodes are recreated. There is unfortunately
no workaround at this stage.

* (Fixed in v1.0.2) ValueMetrics and CounterEvents consumed from the firehose do contain the incorrect `@source` information -
specifically the `@source` information is that of the consuming firehose-to-syslog VM from the PCF Log Search deployment
rather than the information about the VM that generated the metric.
* Disabling the "Enable Shard Allocation" errand and applying changes that affect Elasticsearch nodes will prevent new daily indexes from being created. When updating stemcells it is tempting to disable the "Enable Shard Allocation" errand to speed up the deployment. Unfortunately doing this will leave Elasticsearch in a "broken" state; specifically it will be unable to create new daily indexes at midnight UTC.
<br><br>
If you suspect this has happened, check whether your cluster's `cluster.routing.allocation.enable` setting has been set to something other than `all` by querying: `http://logsearch.<system_domain>/elasticsearch/_cluster/settings?pretty`. If it has, you can correct this by re-enabling the errand in Ops Manager via the Log Search > Errand screen, and Applying Changes.
### Notes
* The Log Search tile for Pivotal Cloud Foundry (PCF) is now generally available.