CeilometerKiloDesignSummitTrack

	A	B	C	D	E	F	G	H	I	J
1	Title	Proposer	Leader	Summary	Theme	Requires a full slot?	Spec (if available)	Interested? (add IRC nick here)	Votes	Topic for Friday?
2	Bringing Gnocchi and Ceilometer together	Julien Danjou	Julien Danjou	Defining the plan during Kilo to improve Ceilometer and Gnocchi cooperation, including migration and co-existence issues.	Gnocchi	maybe		ildikov, eglynn, llu, jd, DinaBelova, gordc, nadya	7
3	Individual Meter/Sample Retention Policy	Fabio Giannetti	Fabio Giannetti	Define a retain value for poll data as well as notifications to identify the time individual samples or meters are stored in the database and what action is taken after it expires (e.g. export to backup etc ..)	Configurability	no (20min)	https://review.openstack.org/128391	nealph (I think there's a general theme here on "allow deployers to reduce stored data" that needs discussing), srsakhamuri	2
4	Notification Filter	Fabio Giannetti	Fabio Giannetti	Create a pipeline like (or extend it) to explicitly state a filter to store only relevant notifications	Configurability	no (20min)	https://review.openstack.org/128411	nealph (I think there's a general theme here on "allow deployers to reduce stored data" that needs discussing), nadya (+1 to nealph), srsakhamuri	3	fabiog, eglynn
5	Role Base Access Control for Ceilometer API	Fabio Giannetti	Fabio Giannetti	Use a policy based approach to control access to API with a greater granularity (KS role based)	Security	no (20min)	https://review.openstack.org/112137	DinaBelova (I'm interested in topic itself, not sure it needs the design session)	1	fabiog, eglynn
6	Configuration (pipeline) using persistent data store	Phil Neal	Phil Neal	Store polling/notifications configurations into a durable data store for dynamic changes without service re-start	Configurability	no (20min)	https://review.openstack.org/127086/	ildikov, llu, DinaBelova, eglynn, nealph, fabiog, lsmola, nadya	8
7	Functional areas to target for collaboration with Monasca	Eoghan Glynn	Eoghan Glynn	Identify common functional areas such as alarming where we can share or converge implementations: alarming, anomaly detection, high-throughput messaging over Kafka for example.	Monasca	yes		ildikov, llu, eglynn, jd, DinaBelova, fabiog,srsakhamuri	7
8	Apply Limit/Next for open ended queries	Fabio Giannetti/Phil Neal	Fabio Giannetti/Phil Neal	Use the limit and next concept to prevent open ended queries (e.g. get meters). This can be set as a configuration parameter and a next/remaining can be used to request the following content.	Configurability	no (20min)	https://review.openstack.org/128418	lsmola, srsakhamuri (this can potentially lead into a new API for ceilometer that addresses these issues with the v2 API)	2	fabiog, eglynn
9	Switchover to in-tree functional tests	Eoghan Glynn	Eoghan Glynn	Figure out the implications of switching over from Tempest coverage to the new project-specific functional testing approach	Testing	no (20min)		ildikov, eglynn, llu, jd, DinaBelova	5
10	Mapping gnocchi semantics to InfluxDB/OpenTSDB	Eoghan Glynn	Eoghan Glynn, Dina Belova	Revisit the gaps in InfluxDB in the light of new features added since mid-cycle and the emerging archive policy features in gnocchi, consider the implications of getting Influx into the CI gate. As for the OpenTSDB, we need some solution for the archiving policies and aggregation functions that will cover both TSDBs + Swift at least + OpenTSDB has no retention policies for now, although HBase has	Gnocchi	yes (min ~30mins, not less)		eglynn, jd, DinaBelova, gordc, nadya	5
11	Metering Ceph storage cluster	Pradeep Kilambi	Pradeep Kilambi	Discuss proposal to add metering support for Ceph Storage to incorporate metrics such as health, status, quorum_status, mon_status, iops, usage and hosts reporting.	Metering	no (20min)		lsmola	1	eglynn
12	Alarm Enhancements	Pradeep Kilambi	Pradeep Kilambi	Propose enhancements around alarm scoping to be global instead of resource specific, add a alarm state filter (low, moderate, critical) and include resource metadata as part of the triggered alarms.	Configurability	no (20min)		nadya(I think it's worth to discuss alarming feature especially alarms + gnocchi, are they gonna exist together, the same about events), Dina: I would say that might be part of very first session proposed here	2	eglynn
13	Kafka Publisher	Yathiraj Udupi/ Debo Dutta	Yathiraj Udupi / Debo Dutta	Discuss adding a new Ceilometer Publisher that will act as a Kafka Producer publishing ceilometer metrics to Kafka. This publisher can be provided as an option in the pipeline file along with the required Kafka configuration options such as the connection details, Kafka topic names.	Configurability	no (20min)		jd, DinaBelova, gordc, fabiog,srsakhamuri	5
14	pollster self-disable mechanism	Lianhao Lu	Lianhao Lu	With more & more pollsters, we need to have a mechanism to disable the pollster in the following cases to avoid spamming exception logs and doing polling which is known to to be a failure in advance: 1. in loading time, mis-configured pollsters shouldn't be loaded, e.g. compute node pollsters configured with wrong hypervisor inspector, ipmi pollsters enabled without ipmitool installed, etc. 2. in runtime, if we see a pollster causes multiple exceptions with a certain resource, we might want to remove that resource from that pollster's polling pool in future iteration.	Configurability	no (20min)		llu, lsmola, nadya	3
15	YAML definition for snmp metrics	Lianhao Lu	Lianhao Lu	Currently, we use a python dict defined snmp inspector and different pollsters for snmp metrics, it's ok for a dozen of metrics. But if want to get hundreds of metrics, we probably should change the logic to use a generic pollster with a YAML definition file, that means we can add new snmp metrics by modifying configuration file only.	Configurability	no (20min)		eglynn, lsmola,nealph	3
16	Notifications {as-a-contract, standardization, maximization}	Chris Dent	Julien Danjou	There's a nascent goal to make notification bodies standardized and versioned so that there can be contractual stability between producers and consumers. There's talk of a cross-project topic but I've not seen it solidify. See up and down this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-October/047966.html	Stability	maybe		eglynn, ildikov, DinaBelova, gordc, nealph, fabiog, nadya	7
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