| opendevreview | Pedro Henrique Pereira Martins proposed openstack/cloudkitty master: Introduce start and end dates on rating rules https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 11:28 |
|---|---|---|
| opendevreview | Merged openstack/cloudkitty master: Add rating modules PUT endpoint to v2 API https://review.opendev.org/c/openstack/cloudkitty/+/684747 | 11:58 |
| opendevreview | Merged openstack/cloudkitty master: CI: Remove grenade branch variables https://review.opendev.org/c/openstack/cloudkitty/+/918314 | 12:31 |
| seunghunlee | Hello! | 14:00 |
| mattcrees | o/ | 14:01 |
| rafaelweingartner | #startmeeting cloudkitty | 14:01 |
| opendevmeet | Meeting started Mon May 13 14:01:27 2024 UTC and is due to finish in 60 minutes. The chair is rafaelweingartner. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'cloudkitty' | 14:01 |
| rafaelweingartner | Hello guys! | 14:01 |
| rafaelweingartner | Roll count | 14:01 |
| mattcrees | Hello! | 14:01 |
| rafaelweingartner | \o | 14:01 |
| priteau | o/ | 14:02 |
| mkarpiarz | Hi! | 14:02 |
| rafaelweingartner | #topic Storyboard status | 14:02 |
| rafaelweingartner | priteau: you have been review storyboard | 14:03 |
| rafaelweingartner | do you need some help to conduct the work there? | 14:03 |
| priteau | Feel free to do some triaging, as I won't have much time in the next two weeks | 14:03 |
| rafaelweingartner | ok | 14:04 |
| rafaelweingartner | thanks for the work done so far! | 14:04 |
| rafaelweingartner | about the deprecation of old branches | 14:06 |
| rafaelweingartner | #topic Old branches deprecation/deletion | 14:06 |
| rafaelweingartner | can we delete/remove victoria and wallaby branch? | 14:06 |
| rafaelweingartner | then, we will not have issues such as #link https://review.opendev.org/c/openstack/cloudkitty/+/911119 | 14:06 |
| rafaelweingartner | and #link https://review.opendev.org/c/openstack/cloudkitty/+/911125 | 14:06 |
| priteau | I would vote for removal | 14:07 |
| priteau | Can you propose a patch in the releases repo? | 14:07 |
| mkarpiarz | Same | 14:07 |
| mkarpiarz | (meaning I agree we should remove these branches) | 14:08 |
| seunghunlee | I agree as well | 14:08 |
| rafaelweingartner | Sure | 14:08 |
| rafaelweingartner | I will do so then | 14:08 |
| rafaelweingartner | #topic Target reviews | 14:09 |
| rafaelweingartner | this patch #link https://review.opendev.org/c/openstack/cloudkitty/+/917445, is a cherry-pick | 14:09 |
| rafaelweingartner | I just triggered a recheck to see what happens | 14:09 |
| rafaelweingartner | but if it passes, we can merge it | 14:09 |
| mkarpiarz | OK | 14:10 |
| rafaelweingartner | then, we have #link https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 14:11 |
| rafaelweingartner | which is the start/end dates patch | 14:11 |
| rafaelweingartner | This one has been in the making for quite a while, but it should be fine to merge it. I mean, there might always appear some need to do some twiking, but nothing that should hold the merge. Right? | 14:11 |
| priteau | I still don't fully understand why we need a start timestamp in the database. | 14:13 |
| rafaelweingartner | how do you decide when a rating rule should be applied? | 14:14 |
| rafaelweingartner | This is explained in the spec | 14:14 |
| rafaelweingartner | let's say we want to schedule a new price to start being applied in 01/01/2025 | 14:14 |
| rafaelweingartner | how do you do that? | 14:14 |
| rafaelweingartner | Of course, one can always wake up in 31/12/2024, and run the command at 23:58. Or then, schedule a cron to run. However, that makes a system shaky at best. It is not possible to do a simpel task as scheduling a new price to be applied. | 14:15 |
| priteau | In this case the start time would be 2025-01-01 of course | 14:15 |
| rafaelweingartner | exactly | 14:16 |
| rafaelweingartner | but Cloudkitty does not have a mechanism to do that right now. | 14:16 |
| priteau | That's why you are proposing this patch. I am not objecting to the patch itself, just curious why we could not make it so that (start = NULL) means that the rating rule is valid from anytime in the past | 14:17 |
| rafaelweingartner | ah yes | 14:18 |
| rafaelweingartner | you are talking about the current situation, meaning the migration path | 14:18 |
| rafaelweingartner | from the rules that exist in the database, where there is no start time, to the patch structure, where there is a start time column | 14:18 |
| rafaelweingartner | Start time is mandatory, therefore, we need to define it; according to the definition we created. Otherwise, when we reprocess, we also would be causing problems, as the reprocessing could affect the result. | 14:20 |
| rafaelweingartner | I mean, with the patch, if no start time is passed, the current timestamp is used. | 14:20 |
| rafaelweingartner | with respect to the migration. We can use null and assume it represents that the rule is valid since ever, or use a timestamp as Pedro did | 14:21 |
| rafaelweingartner | there is no difference in the outcome | 14:21 |
| rafaelweingartner | it is just a difference on how to represent things | 14:21 |
| rafaelweingartner | Pedro used the first time stamp when CloudKitty was first created | 14:21 |
| priteau | Does this mean that with this patch, if you create a new rating rule with no extra argument about start/end like before, it will apply only starting at the current time? | 14:21 |
| rafaelweingartner | then you suggested the timestamp 0 | 14:21 |
| rafaelweingartner | exactly | 14:21 |
| rafaelweingartner | and no end | 14:22 |
| rafaelweingartner | which means, a rule that starts now, and is valid forever | 14:22 |
| rafaelweingartner | which is how CLoudKitty works now | 14:22 |
| rafaelweingartner | if I create a rule now, it will be applied in the next processing Cycle | 14:22 |
| priteau | I think this may be an issue because it changes the behaviour of CloudKitty substantially. | 14:23 |
| priteau | Unless I misunderstood | 14:23 |
| priteau | Before this change, you could add a rating rule and then call reprocess on a past period, it would apply the rule to the reprocessing | 14:24 |
| rafaelweingartner | no it does not | 14:24 |
| rafaelweingartner | you still can | 14:24 |
| rafaelweingartner | we implemented reprocessing, we use it quite a lot | 14:24 |
| opendevreview | Pedro Henrique Pereira Martins proposed openstack/cloudkitty master: Introduce start and end dates on rating rules https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 14:24 |
| rafaelweingartner | #link https://review.opendev.org/c/openstack/cloudkitty/+/876643/19/cloudkitty/rating/hash/controllers/mapping.py#155 | 14:24 |
| rafaelweingartner | there is a force parameter to allow operators to create a rating rule in the past, if they wish so | 14:25 |
| rafaelweingartner | but this has effects in the reprocessing, that is why we introduced this flag with a default to false | 14:25 |
| priteau | But if they don't change anything to their workflow. Assume they don't know about these API changes. What happens? | 14:25 |
| rafaelweingartner | I do not get your question | 14:26 |
| rafaelweingartner | you mean, if they try to create a rating rule in the past? | 14:26 |
| rafaelweingartner | Or if they create a rating rule and reprocess? | 14:26 |
| priteau | Ignore the timestamps completely from the operator point of view | 14:26 |
| rafaelweingartner | which timestamp? | 14:27 |
| priteau | start/end | 14:27 |
| rafaelweingartner | the start or the end? Or both? | 14:27 |
| priteau | They create a new rating rule without any start/end because they use the exact same process as before | 14:27 |
| rafaelweingartner | ok | 14:27 |
| priteau | Then they call reprocess on a past period | 14:27 |
| priteau | Will the rating rule be applied to this period? | 14:27 |
| rafaelweingartner | I see, the newly created rating rule is not going to be used | 14:28 |
| rafaelweingartner | as the operator did not inform the start timestamp | 14:28 |
| priteau | And before this change it would have been used | 14:28 |
| rafaelweingartner | yes | 14:28 |
| rafaelweingartner | but before this you could not schedule | 14:28 |
| rafaelweingartner | you would not be able to reprocess "safely", knowing the result | 14:29 |
| rafaelweingartner | It was always using whatever you have | 14:29 |
| priteau | I think there is an argument for keeping the behaviour the same and making start/end more optional. | 14:30 |
| rafaelweingartner | is there? | 14:30 |
| priteau | When we deploy a new cloud, we often make some iterative changes to the rating rules until we get to a "finalised" version | 14:33 |
| priteau | When we are happy with the rating rules, we can reprocess the data to apply them. | 14:33 |
| priteau | That won't work the same anymore. | 14:33 |
| rafaelweingartner | yes, you can do the same | 14:34 |
| rafaelweingartner | just use the force flag with a timestamp in the past, such as the moment when you start the testing for instance | 14:34 |
| rafaelweingartner | or, with the timestamp when you started the project | 14:35 |
| rafaelweingartner | that would actually be more informative for people reviewing those values in the future | 14:35 |
| rafaelweingartner | bear in mind that the patch is implementing the aproved spec: https://github.com/openstack/cloudkitty-specs/commit/fe84ac27c55ab05301582484979e8a9f72a538b0 | 14:36 |
| priteau | But you see that it requires changes from the client side, we are breaking compatibility. If we had microversions it would be less of a worry. | 14:36 |
| rafaelweingartner | I see what you mean, but it is a communication detail | 14:37 |
| rafaelweingartner | that we can do | 14:37 |
| rafaelweingartner | and propagate this message to operators via the release notes, for instance | 14:37 |
| rafaelweingartner | for setups already in production that would probably not be a problem | 14:37 |
| rafaelweingartner | as people would not normally change rating rules in the past | 14:38 |
| rafaelweingartner | as a matter of fact, the only reason for this to happen, and then to trigger a reprocessing that we saw | 14:38 |
| rafaelweingartner | was when new prices had to be applied, and people would create the new price rule, and reprocess | 14:39 |
| rafaelweingartner | as we did not have a schedule mechanism | 14:39 |
| rafaelweingartner | after doing that, it has been 2 years that we have not seen the need for such process | 14:39 |
| priteau | At the very least we need to document better the behaviour change | 14:41 |
| rafaelweingartner | Ok | 14:42 |
| rafaelweingartner | I will discuss with Pedro | 14:42 |
| rafaelweingartner | can you suggest what you have in mind? | 14:42 |
| priteau | At least an upgrade note describing the behaviour change | 14:43 |
| rafaelweingartner | ok | 14:43 |
| priteau | Something in doc/source too would be nice | 14:43 |
| rafaelweingartner | thanks for the insights | 14:43 |
| rafaelweingartner | besides that, we have #link https://review.opendev.org/c/openstack/cloudkitty/+/916986 | 14:46 |
| rafaelweingartner | which needs some update/checking as the gate is passing | 14:46 |
| priteau | I've rebased it | 14:48 |
| rafaelweingartner | ok, thanks! | 14:48 |
| rafaelweingartner | and, I guess that was all from our side | 14:49 |
| rafaelweingartner | do you guys have something else to add? | 14:49 |
| mkarpiarz | Nope | 14:49 |
| priteau | Thanks for getting the stable fixes merged | 14:49 |
| priteau | mkarpiarz: Any news on your new email address? | 14:50 |
| mkarpiarz | Sorry, I need to leave it as is now. | 14:51 |
| rafaelweingartner | thank you all for participating. | 14:51 |
| rafaelweingartner | Have a nice week. | 14:51 |
| rafaelweingartner | #endmeeting | 14:51 |
| opendevmeet | Meeting ended Mon May 13 14:51:57 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:51 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/cloudkitty/2024/cloudkitty.2024-05-13-14.01.html | 14:51 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/cloudkitty/2024/cloudkitty.2024-05-13-14.01.txt | 14:51 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/cloudkitty/2024/cloudkitty.2024-05-13-14.01.log.html | 14:51 |
| priteau | Bye rafaelweingartner | 14:52 |
| seunghunlee | Thank you | 14:53 |
| opendevreview | Pedro Henrique Pereira Martins proposed openstack/cloudkitty master: Introduce start and end dates on rating rules https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 19:00 |
| opendevreview | Pedro Henrique Pereira Martins proposed openstack/cloudkitty master: Introduce start and end dates on rating rules https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 19:04 |
| opendevreview | Pedro Henrique Pereira Martins proposed openstack/cloudkitty master: Introduce start and end dates on rating rules https://review.opendev.org/c/openstack/cloudkitty/+/876643 | 20:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!