| *** toabctl has quit IRC | 06:18 | |
| *** toabctl has joined #openstack-monasca | 06:22 | |
| *** witek has joined #openstack-monasca | 08:14 | |
| *** witek has quit IRC | 08:33 | |
| *** witek has joined #openstack-monasca | 08:34 | |
| *** arseni-lipinski has quit IRC | 09:56 | |
| *** ivve has joined #openstack-monasca | 10:27 | |
| *** openstackstatus has quit IRC | 10:59 | |
| *** trident has quit IRC | 11:46 | |
| *** trident has joined #openstack-monasca | 11:49 | |
| *** arseni-lipinski has joined #openstack-monasca | 12:25 | |
| openstackgerrit | Arseni Lipinski proposed openstack/monasca-api master: Add build and installation for monasca-kibana-plugin in new API https://review.opendev.org/703661 | 12:28 |
|---|---|---|
| *** arseni-lipinski has quit IRC | 12:41 | |
| witek | Courtesy Monasca meeting reminder in 15 minutes in #openstack-monasca: witek, jayahn,iurygregory,ezpz,igorn,haad,sc,joadavis, akiraY,tobiajo,dougsz,fouadben, amofakhar, haru5ny (haruki),kaiokmo,pandiyan,guilhermesp,chaconpiza,hosanai,Wasaac,brtknr,bandorf | 12:45 |
| *** arseni-lipinski has joined #openstack-monasca | 12:49 | |
| *** bandorf has joined #openstack-monasca | 12:57 | |
| Dobroslaw | hi | 12:57 |
| witek | hi Dobroslaw | 12:57 |
| arseni-lipinski | hi | 12:59 |
| bandorf | Hi, everybody, | 13:00 |
| witek | #startmeeting monasca | 13:00 |
| openstack | Meeting started Tue Mar 3 13:00:17 2020 UTC and is due to finish in 60 minutes. The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| *** openstack changes topic to " (Meeting topic: monasca)" | 13:00 | |
| openstack | The meeting name has been set to 'monasca' | 13:00 |
| witek | hello everyone! | 13:00 |
| *** dougsz has joined #openstack-monasca | 13:00 | |
| witek | the agenda for today: | 13:00 |
| witek | https://etherpad.openstack.org/p/monasca-team-meeting-agenda | 13:01 |
| witek | please add if you have any other topics | 13:01 |
| witek | #topic updating alarm definitions | 13:01 |
| *** openstack changes topic to "updating alarm definitions (Meeting topic: monasca)" | 13:01 | |
| bandorf | OK, I will explain a bit | 13:02 |
| witek | please, go on | 13:02 |
| bandorf | This is the topic Martin brought up last week already. | 13:02 |
| bandorf | I've investigated further. | 13:02 |
| bandorf | The reason is quite simple: For an alarm definition, "time" and "times" are not used when updating an alarm definition. | 13:03 |
| bandorf | Besides, I detected that even an update for "function" won't have any impact. | 13:03 |
| bandorf | According to documentation, everything can be updated, apart from "metric name" and "match by". | 13:04 |
| bandorf | And I don't see any reason why the time, times and fucntion shouldn't be updated. | 13:04 |
| bandorf | I was just a bit confused: | 13:04 |
| bandorf | The queries to create the sub alarm definitions and updating sub alarm definitions are really located very close to each other. | 13:05 |
| bandorf | So, I just wanted to confirm if anybody has any idea for a reason why these fields shouldn't be updated? | 13:05 |
| witek | I think times, time and function could be encapsulated in `expression` | 13:07 |
| bandorf | expression is stored for the alarm definition. | 13:07 |
| witek | alright | 13:08 |
| bandorf | For sub-alarm-definition, the expression is split up into function, operator, metric-name, time, times etc | 13:08 |
| witek | fine | 13:08 |
| bandorf | So, the expression in the alarm definition is stored correctly, even after an update. | 13:08 |
| dougsz | I wonder if it is a thresholder limitation, or just an oversight | 13:08 |
| bandorf | But sub-alarm definitions are not properly handled | 13:08 |
| bandorf | dougsz: That's exactly why I wanted to discuss it here | 13:09 |
| dougsz | I would be tempted to hack in support for updates and see if it behaves | 13:10 |
| bandorf | I did that already, but haven't tested extensively yet. | 13:11 |
| dougsz | Cool, I am guessing there is no tempest coverage? | 13:11 |
| bandorf | As said: "function" (min, max, avg, ...) won't be reflected either in the update | 13:11 |
| bandorf | No, not at all. That's even not that easy to do - a further topic, maybe for the next call | 13:11 |
| bandorf | For the other params that must not be updated, checks have been implemented to prevent that. | 13:12 |
| bandorf | But not for those... | 13:12 |
| witek | we have `test_update_alarm_definition` | 13:12 |
| bandorf | No, not at all: it's related to tempest tests. | 13:12 |
| witek | but it updates from empty expression | 13:13 |
| bandorf | This error is even difficult to detect in tempest tests: You can't read the sub-alarm definitions via api. It's not a logical entity for the user | 13:13 |
| bandorf | And the expression itself, stored for the alarm definition is always correct | 13:14 |
| witek | also I guess it just reads from alarm_definitions table, so won't find this bug | 13:14 |
| bandorf | Exactly. | 13:14 |
| dougsz | An indirect test, like checking an alarm fires with the new expression could work | 13:14 |
| bandorf | Yes, that's one of the possible solutions | 13:14 |
| witek | we would need a test which proves for more realistic scenario with test values and triggered alarm state change | 13:15 |
| witek | :) | 13:15 |
| bandorf | Another option would be to extend the API, so that sub alarm definitions can be read | 13:15 |
| witek | you mean the response body, right? | 13:16 |
| bandorf | I thought about a new operation: get sub alarm defs for an alarm def | 13:17 |
| bandorf | Not intended for end-users | 13:17 |
| witek | I'm not sure I like it, I'd prefer adding more details to existing requests | 13:18 |
| dougsz | My concern would be that it would expose what could be considered 'implementation detail' | 13:19 |
| bandorf | Well, the "problem" is, that sub alarm definitions are not visible for end-users. They just see alarm defs and the related expression. | 13:19 |
| bandorf | dougsz: Yes, you're right | 13:19 |
| bandorf | What I anyway want to avoid is direct access to the database. | 13:20 |
| bandorf | So, there are only 2 options: | 13:20 |
| bandorf | Indirect testing (but that may take long, waiting for an alarm with e..g 2*2 minutes | 13:21 |
| bandorf | Or extending the API somehow | 13:21 |
| dougsz | I feel quite happy with the first approach. I think having to wait for the alarm to fire is acceptable. | 13:22 |
| *** arseni-lipinski has quit IRC | 13:22 | |
| dougsz | It could all be done via tempest too right, just polling for alarms | 13:23 |
| bandorf | Yes. | 13:23 |
| dougsz | i suppose before putting effort into that test, it would be nice to know if your patch works with some manual testing | 13:24 |
| bandorf | In an error situation you still don't know where the problem is located (from updating alarm def. to triggering of alarms). | 13:24 |
| bandorf | However, I think, we could live with this. | 13:24 |
| witek | we could add some debug logging in API | 13:25 |
| dougsz | +1, that could help | 13:25 |
| bandorf | dougsz: Yes, of course. As said, I did already some testing - lokks good so far. Now, wanted to check if anybody knows any reason why these params shouldn't be updated. | 13:26 |
| bandorf | Yes, I started already to add some debug logging. | 13:26 |
| dougsz | excellent | 13:26 |
| bandorf | OK, let me summarize: | 13:27 |
| witek | it seems to me to be a bug, indeed, another option could be, that thresholding is a limitation here | 13:27 |
| bandorf | o Nobody knows a concrete reason why not to do the update, but not 100% sure | 13:28 |
| dougsz | agreed, it either needs a doc fix, or a code fix | 13:28 |
| bandorf | To dos: Fix the issue, extend logging, extend tempest tests with a scenario that checks via alarms | 13:29 |
| bandorf | Doc fix would be sufficent from your point of view? | 13:29 |
| dougsz | Actually, we would probably want to prevent the operation as well, if the patch doesn't work | 13:30 |
| bandorf | This issue came up with a Japanese customer. I'm not sure yet whether they will request a fix | 13:30 |
| witek | code fix is better, but if it's too expensive, e.g. involves logic change in thresh, we'd have to document and perhaps limit API usage | 13:31 |
| bandorf | As said: I'm pretty sure fix in api is sufficient. Just creation of tempest tests might be some more effort. However, I will exec. more manual tests. We can discuss again next week, when I have the results. | 13:32 |
| witek | great, good work bandorf | 13:33 |
| dougsz | yes, thanks bandorf, good work! | 13:33 |
| bandorf | Thanks | 13:34 |
| witek | do we have anything else to discuss? | 13:35 |
| dougsz | Nothing from me. | 13:35 |
| bandorf | Not from me either | 13:35 |
| witek | we've got some comments on events topic from last week in review | 13:36 |
| witek | https://review.opendev.org/708335 | 13:36 |
| witek | I guess we can follow up next week again | 13:37 |
| witek | #topic PTG | 13:38 |
| *** openstack changes topic to "PTG (Meeting topic: monasca)" | 13:38 | |
| witek | Monasca will not be holding own session during the PTG in Vancouver | 13:38 |
| witek | but we should meet and discuss plans for the next release cycle | 13:38 |
| witek | I though, as we are all in Europe, do you think it would make sense to meet F2F? | 13:39 |
| bandorf | In geneneral, I think F2F is much better, communication is easier. | 13:42 |
| bandorf | I would have to check if we will get a budget... | 13:42 |
| dougsz | I think I exceeded my carbon emissions quota last week burning the monasca notification source code | 13:42 |
| witek | haha | 13:42 |
| dougsz | But it's not impossible | 13:42 |
| witek | so we'd have to come to Bristol ;) | 13:43 |
| dougsz | You'd be most welcome, but I don't want to impose anything on anyone :) | 13:43 |
| witek | I mean, it would only make sense if all parties can participate, we're too small group | 13:44 |
| bandorf | As said, I can't confirm any travel budget for us | 13:44 |
| bandorf | Yes, you're right. | 13:44 |
| dougsz | agreed, perhaps we can discuss again next week | 13:44 |
| bandorf | The least travel cost overall would be created if we do it in Munich, right? | 13:44 |
| bandorf | OK, good idea, let's discuss next week | 13:45 |
| witek | agreed | 13:45 |
| witek | alright, I guess that's all for today then | 13:45 |
| witek | thanks for joining and for the discussion | 13:46 |
| dougsz | thanks all, bye | 13:46 |
| witek | and see you next week | 13:46 |
| witek | bye | 13:46 |
| bandorf | Thanks, bye everybody | 13:46 |
| witek | #endmeeting | 13:46 |
| *** openstack changes topic to "OpenStack Monitoring as a Service | https://wiki.openstack.org/wiki/Monasca" | 13:46 | |
| openstack | Meeting ended Tue Mar 3 13:46:22 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:46 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/monasca/2020/monasca.2020-03-03-13.00.html | 13:46 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/monasca/2020/monasca.2020-03-03-13.00.txt | 13:46 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/monasca/2020/monasca.2020-03-03-13.00.log.html | 13:46 |
| *** bandorf has quit IRC | 14:20 | |
| joadavis | I'm shedding a tear for missing out on the PTG this time | 15:11 |
| joadavis | question: if there is no Monasca team presence in Vancouver PTG, is there an alternate way to signal to the community that Monasca is still alive? | 15:13 |
| witek | hi joadavis are you planning to travel to Vancouver? | 15:19 |
| witek | dougsz: I assume oneswig will be there, right? | 15:21 |
| joadavis | I would love to go to Vancouver again, but budget and time don't allow | 15:22 |
| witek | the same here | 15:23 |
| dougsz | witek, I think so, I will ask when he is next around, he could be a potential flyer of the flag | 15:23 |
| joadavis | it might be worth at least a post to the mailing list to share that there won't be a Monasca gathering but give alternate ways to connect. | 15:25 |
| joadavis | That would probably be obvious to most openstack veterans, but as we are trying to build some Monasca interest it might not hurt | 15:26 |
| witek | good idea, we should announce the team planning meeting in the mailing list | 15:26 |
| dougsz | witek, joadavis, what were we thinking of signing oneswig up to? | 15:59 |
| dougsz | project update session or something? | 16:00 |
| witek | I don't think there is anything like that planned in Vancouver | 16:01 |
| dougsz | Lightning talk perhaps? | 16:01 |
| witek | we could have proposed a monitoring panel session, but I'm not aware of such as of now | 16:01 |
| witek | it's not a regular Summit this time around | 16:02 |
| witek | more of developer+operator meetup | 16:02 |
| dougsz | Ok, thanks, he is going at least, so if we think of anything.. | 16:26 |
| witek | I think bringing up Monasca in the Large Scale SIG or some operators meeting would be good | 16:28 |
| dougsz | That makes sense | 16:34 |
| joadavis | If possible, we should make sure he has some Monasca stickers to hand out too. :) | 16:35 |
| dougsz | I'll tell him I pushed back on the suggestion for the lizard outfit :D | 16:37 |
| witek | :) your sense of humor sharpens every day | 16:39 |
| *** ivve has quit IRC | 16:44 | |
| joadavis | :D | 17:06 |
| *** witek has quit IRC | 18:17 | |
| *** vishalmanchanda has quit IRC | 18:59 | |
| *** trident has quit IRC | 20:23 | |
| *** trident has joined #openstack-monasca | 20:26 | |
| *** dougsz has quit IRC | 20:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!