14:01:27 <rafaelweingartner> #startmeeting cloudkitty
14:01:27 <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:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:27 <opendevmeet> The meeting name has been set to 'cloudkitty'
14:01:32 <rafaelweingartner> Hello guys!
14:01:35 <rafaelweingartner> Roll count
14:01:54 <mattcrees> Hello!
14:01:59 <rafaelweingartner> \o
14:02:06 <priteau> o/
14:02:14 <mkarpiarz> Hi!
14:02:52 <rafaelweingartner> #topic Storyboard status
14:03:00 <rafaelweingartner> priteau: you have been review storyboard
14:03:11 <rafaelweingartner> do you need some help to conduct the work there?
14:03:43 <priteau> Feel free to do some triaging, as I won't have much time in the next two weeks
14:04:21 <rafaelweingartner> ok
14:04:46 <rafaelweingartner> thanks for the work done so far!
14:06:04 <rafaelweingartner> about the deprecation of old branches
14:06:13 <rafaelweingartner> #topic Old branches deprecation/deletion
14:06:35 <rafaelweingartner> can we delete/remove victoria and wallaby branch?
14:06:51 <rafaelweingartner> then, we will not have issues such as #link https://review.opendev.org/c/openstack/cloudkitty/+/911119
14:06:59 <rafaelweingartner> and #link https://review.opendev.org/c/openstack/cloudkitty/+/911125
14:07:12 <priteau> I would vote for removal
14:07:31 <priteau> Can you propose a patch in the releases repo?
14:07:34 <mkarpiarz> Same
14:08:02 <mkarpiarz> (meaning I agree we should remove these branches)
14:08:23 <seunghunlee> I agree as well
14:08:32 <rafaelweingartner> Sure
14:08:35 <rafaelweingartner> I will do so then
14:09:07 <rafaelweingartner> #topic Target reviews
14:09:46 <rafaelweingartner> this patch #link https://review.opendev.org/c/openstack/cloudkitty/+/917445, is a cherry-pick
14:09:54 <rafaelweingartner> I just triggered a recheck to see what happens
14:09:59 <rafaelweingartner> but if it passes, we can merge it
14:10:18 <mkarpiarz> OK
14:11:08 <rafaelweingartner> then, we have #link https://review.opendev.org/c/openstack/cloudkitty/+/876643
14:11:14 <rafaelweingartner> which is the start/end dates patch
14:11:55 <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:13:06 <priteau> I still don't fully understand why we need a start timestamp in the database.
14:14:05 <rafaelweingartner> how do you decide when a rating rule should be applied?
14:14:12 <rafaelweingartner> This is explained in the spec
14:14:32 <rafaelweingartner> let's say we want to schedule a new price to start being applied in 01/01/2025
14:14:34 <rafaelweingartner> how do you do that?
14:15:55 <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:55 <priteau> In this case the start time would be 2025-01-01 of course
14:16:02 <rafaelweingartner> exactly
14:16:23 <rafaelweingartner> but Cloudkitty does not have a mechanism to do that right now.
14:17:44 <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:18:16 <rafaelweingartner> ah yes
14:18:29 <rafaelweingartner> you are talking about the current situation, meaning the migration path
14:18:52 <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:20:08 <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:24 <rafaelweingartner> I mean, with the patch, if no start time is passed, the current timestamp is used.
14:21:02 <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:12 <rafaelweingartner> there is no difference in the outcome
14:21:24 <rafaelweingartner> it is just a difference on how to represent things
14:21:40 <rafaelweingartner> Pedro used the first time stamp when CloudKitty was first created
14:21:45 <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:46 <rafaelweingartner> then you suggested the timestamp 0
14:21:58 <rafaelweingartner> exactly
14:22:03 <rafaelweingartner> and no end
14:22:14 <rafaelweingartner> which means, a rule that starts now, and is valid forever
14:22:19 <rafaelweingartner> which is how CLoudKitty works now
14:22:30 <rafaelweingartner> if I create a rule now, it will be applied in the next processing Cycle
14:23:25 <priteau> I think this may be an issue because it changes the behaviour of CloudKitty substantially.
14:23:40 <priteau> Unless I misunderstood
14:24:07 <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:09 <rafaelweingartner> no it does not
14:24:15 <rafaelweingartner> you still can
14:24:26 <rafaelweingartner> we implemented reprocessing, we use it quite a lot
14:24:28 <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:48 <rafaelweingartner> #link https://review.opendev.org/c/openstack/cloudkitty/+/876643/19/cloudkitty/rating/hash/controllers/mapping.py#155
14:25:06 <rafaelweingartner> there is a force parameter to allow operators to create a rating rule in the past, if they wish so
14:25:22 <rafaelweingartner> but this has effects in the reprocessing, that is why we introduced this flag with a default to false
14:25:50 <priteau> But if they don't change anything to their workflow. Assume they don't know about these API changes. What happens?
14:26:30 <rafaelweingartner> I do not get your question
14:26:39 <rafaelweingartner> you mean, if they try to create a rating rule in the past?
14:26:49 <rafaelweingartner> Or if they create a rating rule and reprocess?
14:26:58 <priteau> Ignore the timestamps completely from the operator point of view
14:27:14 <rafaelweingartner> which timestamp?
14:27:17 <priteau> start/end
14:27:21 <rafaelweingartner> the start or the end? Or both?
14:27:31 <priteau> They create a new rating rule without any start/end because they use the exact same process as before
14:27:37 <rafaelweingartner> ok
14:27:50 <priteau> Then they call reprocess on a past period
14:27:56 <priteau> Will the rating rule be applied to this period?
14:28:06 <rafaelweingartner> I see, the newly created rating rule is not going to be used
14:28:14 <rafaelweingartner> as the operator did not inform the start timestamp
14:28:22 <priteau> And before this change it would have been used
14:28:27 <rafaelweingartner> yes
14:28:39 <rafaelweingartner> but before this you could not schedule
14:29:09 <rafaelweingartner> you would not be able to reprocess "safely", knowing the result
14:29:17 <rafaelweingartner> It was always using whatever you have
14:30:44 <priteau> I think there is an argument for keeping the behaviour the same and making start/end more optional.
14:30:57 <rafaelweingartner> is there?
14:33:10 <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:29 <priteau> When we are happy with the rating rules, we can reprocess the data to apply them.
14:33:36 <priteau> That won't work the same anymore.
14:34:38 <rafaelweingartner> yes, you can do the same
14:34:55 <rafaelweingartner> just use the force flag with a timestamp in the past, such as the moment when you start the testing for instance
14:35:29 <rafaelweingartner> or, with the timestamp when you started the project
14:35:43 <rafaelweingartner> that would actually be more informative for people reviewing those values in the future
14:36:15 <rafaelweingartner> bear in mind that the patch is implementing the aproved spec: https://github.com/openstack/cloudkitty-specs/commit/fe84ac27c55ab05301582484979e8a9f72a538b0
14:36:30 <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:37:17 <rafaelweingartner> I see what you mean, but it is a communication detail
14:37:21 <rafaelweingartner> that we can do
14:37:42 <rafaelweingartner> and propagate this message to operators via the release notes, for instance
14:37:55 <rafaelweingartner> for setups already in production that would probably not be a problem
14:38:21 <rafaelweingartner> as people would not normally change rating rules in the past
14:38:46 <rafaelweingartner> as a matter of fact, the only reason for this to happen, and then to trigger a reprocessing that we saw
14:39:03 <rafaelweingartner> was when new prices had to be applied, and people would create the new price rule, and reprocess
14:39:10 <rafaelweingartner> as we did not have a schedule mechanism
14:39:32 <rafaelweingartner> after doing that, it has been 2 years that we have not seen the need for such  process
14:41:34 <priteau> At the very least we need to document better the behaviour change
14:42:37 <rafaelweingartner> Ok
14:42:41 <rafaelweingartner> I will discuss with Pedro
14:42:48 <rafaelweingartner> can you suggest what you have in mind?
14:43:23 <priteau> At least an upgrade note describing the behaviour change
14:43:36 <rafaelweingartner> ok
14:43:42 <priteau> Something in doc/source too would be nice
14:43:47 <rafaelweingartner> thanks for the insights
14:46:25 <rafaelweingartner> besides that, we have #link https://review.opendev.org/c/openstack/cloudkitty/+/916986
14:46:36 <rafaelweingartner> which needs some update/checking as the gate is passing
14:48:22 <priteau> I've rebased it
14:48:42 <rafaelweingartner> ok, thanks!
14:49:09 <rafaelweingartner> and, I guess that was all from our side
14:49:16 <rafaelweingartner> do you guys have something else to add?
14:49:55 <mkarpiarz> Nope
14:49:56 <priteau> Thanks for getting the stable fixes merged
14:50:24 <priteau> mkarpiarz: Any news on your new email address?
14:51:39 <mkarpiarz> Sorry, I need to leave it as is now.
14:51:44 <rafaelweingartner> thank you all for participating.
14:51:53 <rafaelweingartner> Have a nice week.
14:51:57 <rafaelweingartner> #endmeeting