CeilometerLibertyDesignSummitTrack
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

Comment only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
VOTING STARTS -- APRIL30
2

3
TitleProposerLeaderSummaryThemeRequires a full slot?Spec (if available)Interested? (add IRC nick here)Votes
Session type (2fishbowl/8working/1meetup)
4
OPs Meetup outcome
ildikovPlaceholder to discuss the feedback from the Ops MeetupFeedbackTBD
https://etherpad.openstack.org/p/YVR-ops-meetupfabiog, eglynn, prad, jd, cdent
5
Ceilometer Multiple Identitycdentjd can lead if you not afraid!Ceilometer has many fuzzy identities but one big messy repo alongside 3 other (much less messy) repos. What is Ceilometer? What should it be? Would it be more clear with more clear repos?FutureYeshttps://etherpad.openstack.org/p/ceilo-multi-identityfabiog, eglynn, prad, ildikov, jd, sileht, llu, dbelova, cdent
6
Declarative notification handlingpradCurrently adding new event notifications in ceilometer involves writing a routine sequence of repetitive code over and over. This proposal is to do this in a more declarative approach by defining the notification topic info through a yaml or a json file and a generic notification handler handles the rest. This allows us to selectively listen to services and end user doesnt have to worry about writing much code and focus on the data that needs to be captured.NotificationsYes
https://etherpad.openstack.org/p/ceilo-declarative-notifications
cdent, llu, eglynn
7
getting more out of eventsr-mibu(Ryota)we have quite a few specs to either alarm on events (ie. a state change) or build meters from events (ie. time between start/stop events). this session is to discuss how we can leverage the data and the event pipeline to accommodate all such use casesEvents/notificationspossibly?https://review.openstack.org/#/c/172893/llu, ildikov
8
pipeline configuration on flynadya/rjaiswaldbelova/Rob Parker (HP)we still have concerns about the scope of problems that should be resolved within Ceilometer. Do we want to synchronize configs or just reload it? Do we want to have API for changing pipeline configs? This session is to discuss these questions and maybe find out how the other projects manage with such a 'configuration mess'
ConfigurationNot sure, maybe a part of ops session?https://review.openstack.org/#/c/171826/ildikov, cdent, fabiog, dbelova
9
samples and events convergence/distinctiongordcwe are transistioning to meters == measurement, events == ... events? this is to talk about what events we want (healthcheck/existence)? and not to make a connection between resources, metrics, and events.events/samplesnojd, llu, cdent
10
Ceilometer ComponetaizationfabiogCeilometer has grown in a complex code base that has several functions mixed together and it makes it difficult to maintain and integrate with other solutions. I believe we should start creating several components out of the Ceilometer project that are focussed on the specific aspect, for instance Ceilometer-Collection would be a repo that focusses only in collecting metrics or events. Then we could have a Ceilometer-Metrics, Ceilometer-Event and Ceilometer-Alarms that are different services with the database technology that makes sense for these (and not the full matrix of combinations). Lastly we could even have a Ceilometer-Configuration that is a standalone server dedicated in configuring the other parts.DesignYesfabiog, llu
I think this overlaps a bit with Ceilometer Multiple Identity -- jd
11
event alarmyuntongjin / lluIn some use cases like NFV, we want to build an alarm based on
event/notification, and trigger the alarm immediately. This session
want to talk about how to implement that event based alarm.
Events/notificationspossibly?https://etherpad.openstack.org/p/event_alarmjd, sileht, cdent
12
olso.versioned objects adoption
eglynnTalk through the value that ceilometer could potentially derive from adopting the oslo.versioned objects library fork-lifted out of novaMigrationhttps://review.openstack.org/172427sileht, cdent, llu
13
Meter deprecationildikovIdentify the process that we would like to follow to deprecate meters for deleting, renaming or for other changesDeprecationPossibly?
14
15
16
17
18
19
20
GORD TYPING
21
ceilometer componentization/multiple identitycdent/fabiogwed 9amfishbowl
22
event alarms
r-mibu / yuntongjin / llu
wed 9:50amfishbowl
23
pipeline configuration on the flynadya/rjaiswalwed 11am
24
declarative notificationspradwed 11:50am
25
ops placeholderildikovwed 2:40pm
26
open discussion (probably continuation of 'multiple identity' madness)
wed 3:30pm
27
28
meter deprecationildikovthurs 9am
29
samples/events integrationgordcthurs 9:50am
30
oslo.versionedeglynnthurs 11:00am
31
open discussion (probably continuation of 'multiple identity' madness)
thurs 11:50am
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
Loading...