| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Fix HTTP 500 on the Audits page in non-English languages https://review.opendev.org/c/openstack/watcher-dashboard/+/1012875 | 03:48 |
|---|---|---|
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Fix HTTP 500 on the Audits page in non-English languages https://review.opendev.org/c/openstack/watcher-dashboard/+/1015292 | 03:57 |
| opendevreview | chandan kumar proposed openstack/watcher master: [DNM] testing unified operator and S2I content provider job for watcher https://review.opendev.org/c/openstack/watcher/+/1015294 | 04:06 |
| opendevreview | chandan kumar proposed openstack/watcher master: [DNM] testing unified operator and S2I content provider job for watcher https://review.opendev.org/c/openstack/watcher/+/1015294 | 04:07 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Fix Audits page HTTP 500 in non-English locales https://review.opendev.org/c/openstack/watcher-dashboard/+/1012875 | 04:28 |
| opendevreview | Douglas Viroel proposed openstack/watcher-specs master: Add spec for availability zone drain https://review.opendev.org/c/openstack/watcher-specs/+/1007853 | 13:00 |
| dviroel | #startmeeting watcher | 13:00 |
| opendevmeet | Meeting started Thu Nov 12 13:00:39 2026 UTC and is due to finish in 60 minutes. The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| opendevmeet | The meeting name has been set to 'watcher' | 13:00 |
| dviroel | hello folks o/ | 13:01 |
| jgilaber | o/ | 13:01 |
| dviroel | who is around? | 13:01 |
| chandankumar | o/ | 13:01 |
| winiciusallan[m] | o/ | 13:01 |
| dviroel | courtesy ping: amoralej sean-k-mooney morenod | 13:02 |
| morenod | o/ | 13:02 |
| dviroel | while folks join the meeting | 13:02 |
| dviroel | let me add the meeting agenda | 13:02 |
| dviroel | #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L28 (Meeting agenda) | 13:02 |
| dviroel | this is our agenda for today | 13:02 |
| sean-k-mooney | o/ | 13:02 |
| dviroel | feel free to add topics to the agenda | 13:02 |
| dviroel | lets see how can we cover | 13:03 |
| dviroel | #topic https://blueprints.launchpad.net/watcher/+spec/watcher-openstacksdk | 13:03 |
| dviroel | jgilaber: spec | 13:03 |
| dviroel | "Watcher suppport in OpenstackSDK" | 13:03 |
| jgilaber | yes, we merged the spec this week | 13:03 |
| jgilaber | so I created the blueprint for it | 13:04 |
| amoralej | o/ | 13:04 |
| dviroel | right | 13:04 |
| dviroel | cool, I think I can quickly review it and set the approval | 13:05 |
| dviroel | thanks jgilaber | 13:05 |
| jgilaber | thanks dviroel | 13:05 |
| jgilaber | that's all for this topic | 13:05 |
| dviroel | ah o | 13:05 |
| dviroel | was about to ask :) | 13:05 |
| dviroel | someone wants to add something? | 13:05 |
| dviroel | next topic then | 13:06 |
| dviroel | #topic Updates to Availability Zone Drain Spe | 13:06 |
| dviroel | there was a round of reviews in this spec | 13:06 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher-specs/+/1007853 | 13:06 |
| dviroel | ty for reviewing it | 13:06 |
| dviroel | it is getting bigger | 13:07 |
| dviroel | some updates and outcomes from it, after discussing here in the IRC and in the spec itself | 13:07 |
| dviroel | sean-k-mooney: had the idea of including "availability_zone_pinning_policy" which allow users to select how the plan should handle the pinning | 13:08 |
| dviroel | which I think that is a good way of proposing it, and to extend it in the future | 13:08 |
| sean-k-mooney | basicly 3 option alwasy pin, never pin, and pin if it was pinned before the move | 13:08 |
| dviroel | other than a boolean | 13:08 |
| amoralej | for instances previously pinned, right? | 13:08 |
| dviroel | right | 13:08 |
| sean-k-mooney | amoralej: no for all instnaces | 13:08 |
| sean-k-mooney | well that are moved | 13:08 |
| sean-k-mooney | auto which woudl be the pin if it was already pinned case | 13:09 |
| dviroel | all instances in the action plan | 13:09 |
| sean-k-mooney | coudl be the default | 13:09 |
| sean-k-mooney | ya that | 13:09 |
| sean-k-mooney | i woudl be a high level plocy for the audit not a per instnace setting in the input parmaters | 13:10 |
| amoralej | what'd be the case for always? isn't that weird? | 13:10 |
| dviroel | the new spec PS has 4 options now tbh | 13:10 |
| amoralej | i mean, pinning a vm which was unpinned before | 13:10 |
| dviroel | it is an option.. | 13:11 |
| sean-k-mooney | amoralej: if you are chaing the az in the first place its likely that you dont want that policy decsion to be lost in the furue | 13:11 |
| dviroel | the same way that unpin_only is too | 13:11 |
| sean-k-mooney | right so if you moved everythign because your draingin you mign not want the workload stablistatoin policy to move it back an hour later | 13:11 |
| sean-k-mooney | if you do leave it un pinned | 13:12 |
| sean-k-mooney | if you dont pin it | 13:12 |
| amoralej | ok | 13:12 |
| amoralej | and wrt the default zone, the decission was to never pin to it, right? | 13:12 |
| dviroel | yeah, i forgot that in yesterday's PS, but I just added | 13:12 |
| sean-k-mooney | that woudl be consitent with nova docs | 13:13 |
| dviroel | the decision is to never pin to it | 13:13 |
| sean-k-mooney | its still tbd if we are going to make that a hard error or not | 13:13 |
| sean-k-mooney | on the nova side | 13:13 |
| sean-k-mooney | but ya i woudl prefer to never pin to the default az | 13:13 |
| sean-k-mooney | we are trending in the direction | 13:13 |
| sean-k-mooney | of changing how the az is reproted for host in the default az | 13:14 |
| sean-k-mooney | by reporting either `""` or `internal` | 13:14 |
| sean-k-mooney | and then not inlcuding it in the AZ list | 13:14 |
| dviroel | some other discussions in the spec: | 13:14 |
| amoralej | and for pinned instances to the default one, it's treated as any other zone, right? | 13:14 |
| amoralej | so, a vm pined to nova (or default zone) will not be migrated if include_az_pinned_instance is false | 13:15 |
| sean-k-mooney | amoralej: righ tnow there is a bug in the schduler and yes effeictlvy but that may become a hard error | 13:15 |
| sean-k-mooney | unless you have create a host aggrate with the az metadata with the same name | 13:15 |
| amoralej | in case src_az is nova, i mean | 13:15 |
| sean-k-mooney | oh well for souce az we would still supprot moving form the default az | 13:16 |
| sean-k-mooney | but as i noted the az reported on the compute node may change to the empty string | 13:16 |
| dviroel | i think that if skippin is enabled, so we would not include it | 13:16 |
| dviroel | if is pinned to the default already | 13:16 |
| amoralej | ok | 13:16 |
| dviroel | i also renamed "skip_az_pinned_instances" to "include_az_pinned_instances". - sean-k-mooney thinks that is better to not include them by default. Different from what we discussed previously | 13:17 |
| amoralej | as soon as it's documented, i think it will work | 13:17 |
| sean-k-mooney | the main reason for the rename is to avoid the double negitive | 13:17 |
| sean-k-mooney | i.e skip=false means include | 13:17 |
| sean-k-mooney | which is a double negitive | 13:17 |
| dviroel | ack, makes sense | 13:17 |
| amoralej | yes, include_ seems more clear to me | 13:18 |
| jgilaber | the new option has the advantage of circumventing the problem we discussed about stale AZ info in the CDM | 13:18 |
| jgilaber | for the always and never pin option | 13:18 |
| jgilaber | the default auto would still have the same issue | 13:19 |
| jgilaber | I haven't check the last PS, not sure if you're updated that dviroel | 13:19 |
| dviroel | yes I updated | 13:19 |
| dviroel | the auto may still move a pinned instances | 13:19 |
| sean-k-mooney | yep, nova only allows you to pin to the az the vm is currely in, any other value will be rejected | 13:19 |
| sean-k-mooney | if its not pinned and you ask for it to be unpinned i thin kthat wont raise an error | 13:20 |
| sean-k-mooney | so worst case in teh auto case if it was stale and we tought it was pinned | 13:20 |
| sean-k-mooney | we woudl move it an pin it | 13:20 |
| sean-k-mooney | if we tought it was not pinned | 13:20 |
| sean-k-mooney | then the move would fail | 13:20 |
| sean-k-mooney | but i think thats fine | 13:20 |
| sean-k-mooney | just runing the auit again woudl work | 13:20 |
| sean-k-mooney | by the way on the staleness i noted that there is an instance update event we get as a notificaion | 13:21 |
| sean-k-mooney | so when we retive that we can just do a server show direct to the nova api to get the pinning info | 13:21 |
| amoralej | dviroel, in the spec, the policy relocate_pin is the auto mode? | 13:21 |
| sean-k-mooney | if nova ever passes that in the notificaon we can optimise | 13:21 |
| dviroel | sean-k-mooney: which event? | 13:21 |
| sean-k-mooney | there is an instance update notificaoin | 13:22 |
| dviroel | ah yeah, but i don't think that it is sent | 13:22 |
| sean-k-mooney | pining and unpiing just use the server update api | 13:22 |
| dviroel | since instance update_dict will be empty | 13:22 |
| dviroel | during save() | 13:22 |
| sean-k-mooney | it should be if not it woudl be a bug | 13:22 |
| dviroel | so it will return early | 13:22 |
| dviroel | that's what I see from the code | 13:22 |
| sean-k-mooney | update_dict shoudl nto be empty | 13:22 |
| sean-k-mooney | it shoudl be seting the pinned_az filed to the empty sting | 13:23 |
| sean-k-mooney | or to the current az name | 13:23 |
| dviroel | i think that is gets that from request_spec | 13:23 |
| dviroel | not from the instance | 13:23 |
| dviroel | so there is no update to the instance obj | 13:23 |
| sean-k-mooney | perhaps but it woudl still be a bug | 13:23 |
| sean-k-mooney | if you did an update on the instance that notificaion should be sent | 13:24 |
| dviroel | it is a PUT to the instance yeah | 13:24 |
| sean-k-mooney | lets file that as a bug and dicsus it with the nova team | 13:24 |
| dviroel | ack | 13:24 |
| sean-k-mooney | if they accpate it we can add a followup to use it in watcher | 13:24 |
| sean-k-mooney | to refhes the instace on instance updates | 13:24 |
| dviroel | amoralej: yes, relocate_pin was a suggestion, but not sure if is the best | 13:25 |
| dviroel | sean-k-mooney: sure, that would work yes | 13:25 |
| dviroel | yes can discuss more after the meeting, and look at code ,etc.. | 13:25 |
| dviroel | wrt to the spec | 13:25 |
| dviroel | there were some other small changes | 13:25 |
| dviroel | please compare with the previous PS that you reviewed and let me know if you all agree with the changes.. | 13:26 |
| amoralej | I will review, i'm not sure skip_conflicting should be a policy option | 13:27 |
| dviroel | teim review also help us to not have any contradictions around the spec | 13:27 |
| dviroel | that somethin that I just added, but would cover the issue with stable model | 13:27 |
| dviroel | s/stable/stale | 13:27 |
| dviroel | and be the default for other strategies | 13:28 |
| amoralej | I will check after the meeting | 13:28 |
| dviroel | i think that we can discuss more in the spec, and in each option | 13:28 |
| dviroel | thanks amoralej | 13:28 |
| sean-k-mooney | oh by the way im usign tomorrow "day of learning" to "learn" how to run teim review on a non outdate k8s with workign logging :) | 13:28 |
| dviroel | oh nice | 13:29 |
| sean-k-mooney | if there are other tweaks or refinements that folks want let me know | 13:29 |
| dviroel | ack | 13:29 |
| amoralej | cool | 13:29 |
| dviroel | anything else that you folks want to chat about zone drain? | 13:29 |
| dviroel | otherwise we should move to the next topic | 13:29 |
| sean-k-mooney | no i will try and review it again today ro monday | 13:30 |
| dviroel | thanks all! | 13:30 |
| sean-k-mooney | but i think we are close to beign able to proceed wit the spec | 13:30 |
| dviroel | yeah, we are closing the gaps | 13:30 |
| dviroel | #topic Update goals and strategies in place feature | 13:30 |
| dviroel | amoralej o/ | 13:30 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/1014571 | 13:31 |
| amoralej | In the review a couple of questions were raised that i'd like to discuss here | 13:31 |
| dviroel | oh, this is not the spec | 13:31 |
| amoralej | oh, my bad with the link sorry | 13:31 |
| dviroel | :) | 13:31 |
| jgilaber | https://review.opendev.org/c/openstack/watcher-specs/+/1012696 | 13:31 |
| amoralej | #undo | 13:31 |
| amoralej | #link https://review.opendev.org/c/openstack/watcher-specs/+/1012696 | 13:32 |
| amoralej | 1st topic is about audit scopes | 13:32 |
| dviroel | right | 13:32 |
| amoralej | as dviroel pointed, in future we may have problems with audit scopes if schemas for scopes change | 13:32 |
| amoralej | so it may be good to implement a similar approach of versioned schemas | 13:33 |
| dviroel | i asked about audit scopes, mainly because i would like to improve it in near future yeah | 13:33 |
| amoralej | currently, the auditscope is only checked when an audit is created | 13:33 |
| amoralej | on execution, it's just consumed and processed on the get_scoped_model | 13:34 |
| amoralej | https://github.com/openstack/watcher/blob/28da878b1ff1b4be820ef946af7c88563d43b9f3/watcher/decision_engine/scope/compute.py#L176 | 13:34 |
| amoralej | so, it may happen if the scope schemas are modified in backwards incompatible ways | 13:34 |
| dviroel | the scope is stored with the audit, right? and there is no check during the sync()? | 13:35 |
| amoralej | said that, imo, given that the syncer is not checking audit scopes, it's out of the scope for this spec | 13:35 |
| amoralej | yes, it's part of the audit | 13:35 |
| amoralej | no | 13:35 |
| dviroel | ack | 13:35 |
| amoralej | scope definition is not in the database | 13:35 |
| amoralej | and sync doesn't care about it | 13:36 |
| dviroel | :( | 13:36 |
| amoralej | it may be good to check if an audit scope conforms with current schema at execution | 13:36 |
| amoralej | and fail the audit otherwise, as first step | 13:36 |
| sean-k-mooney | maybe | 13:37 |
| jgilaber | it seems to be listed in the DB model for an audit https://github.com/openstack/watcher/blob/28e511b7f6a05ea6bfa66e3cc8e65c08b1a93fe0/watcher/db/sqlalchemy/models.py#L182 | 13:37 |
| amoralej | and we could implement upgrade_scope in future | 13:37 |
| sean-k-mooney | but we shoudl not change them in a backward incompatble way | 13:37 |
| sean-k-mooney | that would break upgrades | 13:37 |
| amoralej | yes, i think that should be the default policy | 13:37 |
| dviroel | ok to not include the scope in the current spec | 13:38 |
| sean-k-mooney | well teh scope is already snaphost | 13:38 |
| sean-k-mooney | its snapshot when the auit is create form teh template | 13:38 |
| dviroel | but would be the next thing to fix I think | 13:38 |
| sean-k-mooney | im not sure that it needs to be fixed | 13:38 |
| amoralej | the scope snapshot of the audit is in database | 13:39 |
| sean-k-mooney | yes | 13:39 |
| amoralej | what i meant before is that scope schema is not (as it's for the strategy spec) | 13:39 |
| sean-k-mooney | the schema doe not need to be | 13:39 |
| jgilaber | ah ok I misunderstood you amoralej | 13:39 |
| sean-k-mooney | and the fact that we have it for the stragies is actully kind of weird | 13:39 |
| amoralej | yep, i agree | 13:39 |
| amoralej | ok, so we agree on keeping scope handling out of the scope in this spec? | 13:40 |
| sean-k-mooney | sure | 13:40 |
| jgilaber | +1 | 13:40 |
| amoralej | (scope is overloaded here :) | 13:40 |
| sean-k-mooney | to mean its already snapshot | 13:40 |
| sean-k-mooney | *to me | 13:40 |
| sean-k-mooney | so we dont need to incldue it for now | 13:41 |
| amoralej | the other topic is about how to hande non-versioned out-of-tree strategies. | 13:41 |
| sean-k-mooney | well out of tree stratiges are not suproted by the watcher core team | 13:41 |
| amoralej | there may be deployers using strategies not following the versioning method proposed | 13:41 |
| sean-k-mooney | yep and its there responisbelty to maintian compatiablity themselves | 13:42 |
| sean-k-mooney | we shoudl docuement our expecations but its not a watcher bug if they break | 13:42 |
| amoralej | What i was proposing is that in those cases CONTINUOUS audits will continue active. However, the decision-engine AuditHandler checks if the parameters content pass schema validation, so it will be fine while the changes are backwards compatible. When an audit fails to validate, it will be set to FAILED and leave a clear error in the status_message. | 13:42 |
| sean-k-mooney | ack that sound reasonable | 13:43 |
| amoralej | that's what is currently in the spec, feel free to review the wording there | 13:44 |
| dviroel | ack, sounds goods | 13:44 |
| amoralej | finally, while working on it i found what i consider a pre-existing bug https://review.opendev.org/c/openstack/watcher/+/1014571 | 13:44 |
| amoralej | sorry, that link is wrong | 13:44 |
| amoralej | https://bugs.launchpad.net/watcher/+bug/2174051 | 13:45 |
| dviroel | " Terminated Audits and ActionPlans in SUCCEEDED and FAILED status are CANCELLED by Syncer Edit" | 13:46 |
| amoralej | so, if there is agreement that's a bug on current syncer implemention, i will propose fix before the new feature series | 13:46 |
| * dviroel melting_face | 13:46 | |
| amoralej | short version, an Audit in SUCCEEDED or FAILED is moved to CANCELLED | 13:46 |
| amoralej | if the strategy is updated | 13:46 |
| jgilaber | yes looks valid, I can't imagine any reason to do that | 13:47 |
| sean-k-mooney | yes its a bug and i would triage it as critial or more likely high impornatce | 13:47 |
| dviroel | does the state machine allow that? | 13:47 |
| dviroel | they are final state | 13:47 |
| amoralej | nop | 13:47 |
| * dviroel i think that it doesn't validate | 13:47 | |
| sean-k-mooney | dviroel: the state diagrame does not | 13:47 |
| amoralej | that's what is making grenade jobs to fail in https://review.opendev.org/c/openstack/watcher/+/1014569/ i.e. | 13:47 |
| sean-k-mooney | but because we are not afctully using a state machine explcity | 13:47 |
| sean-k-mooney | it is posisble due ot the direct upates of the db | 13:48 |
| amoralej | yes | 13:48 |
| dviroel | yeah | 13:48 |
| amoralej | i'm also preparing a patch for that | 13:48 |
| sean-k-mooney | there is no enforcement in code on teh avlie transitions | 13:48 |
| sean-k-mooney | we coudl build that eventually | 13:48 |
| sean-k-mooney | but fo now it shoudl just never update stauts that are already terminial | 13:48 |
| amoralej | i think we only validate transitions in the api | 13:48 |
| dviroel | amoralej: patch for what exactly? | 13:48 |
| amoralej | yes | 13:49 |
| amoralej | ok, so i think that's it wrt this topic | 13:49 |
| sean-k-mooney | amoralej: so if we dont already have a cosntat for this i woudl defeint one for the termal states and skip the actions plans and or actions that are already terminal in the sync | 13:49 |
| amoralej | i think we have agreements on all topic, thanks :) | 13:49 |
| amoralej | sean-k-mooney, that's what i'm implementing | 13:50 |
| sean-k-mooney | cool | 13:50 |
| dviroel | ack | 13:50 |
| dviroel | any ther question folks? | 13:50 |
| jgilaber | we should triage the bug now | 13:50 |
| jgilaber | or list it for later | 13:50 |
| amoralej | btw, i sent implementation proposals for the new behavior in https://review.opendev.org/q/topic:%22blueprint-update-goals-and-strategies-in-place%22 | 13:50 |
| dviroel | oh yeah, lets do this now | 13:50 |
| amoralej | if you want to take a look | 13:50 |
| jgilaber | but it should be quick now since we've already discussed | 13:50 |
| dviroel | it is already set to Hig | 13:51 |
| dviroel | which looks fine to me | 13:51 |
| dviroel | jgilaber: agree? | 13:51 |
| sean-k-mooney | dviroel: ya i just set it | 13:51 |
| jgilaber | ah ok | 13:51 |
| dviroel | ack | 13:51 |
| jgilaber | yeah High seems ok for me | 13:51 |
| dviroel | #topic Functional tests | 13:51 |
| dviroel | amoralej: you again | 13:51 |
| amoralej | yes, that's just ask for feedback | 13:51 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/993543 | 13:51 |
| amoralej | i think the main open point is https://review.opendev.org/c/openstack/watcher/+/993543/comment/03229647_25ef63af/ | 13:52 |
| amoralej | no need to discuss now, we are short on time | 13:52 |
| amoralej | but it's just if/how we want to validate metrics consistency between host and instances metrics | 13:52 |
| dviroel | ack, lets keep that thread open there and get more feedback | 13:53 |
| dviroel | i need to revisit it | 13:53 |
| amoralej | yep | 13:53 |
| dviroel | yeah | 13:53 |
| sean-k-mooney | amoralej: long term i would probly add a helper to sync form instnace ot host | 13:53 |
| sean-k-mooney | or visversa | 13:53 |
| sean-k-mooney | but wihtout using it | 13:53 |
| sean-k-mooney | im not sure which we will want to use more | 13:53 |
| sean-k-mooney | i think the patern of updating the isntance metrics | 13:54 |
| sean-k-mooney | tehn callign a method on the host to refcaluate the host values form the instnace on the host | 13:54 |
| sean-k-mooney | will be the simplest | 13:54 |
| amoralej | it's tricky because we may want to simulate cases for different host usage out of instances, etc... ceph, etc... | 13:54 |
| sean-k-mooney | but ya i dont have a stong opion right now either way | 13:54 |
| amoralej | we could parametrize | 13:54 |
| amoralej | but anyway, let's discuss in the review | 13:54 |
| dviroel | there are different use cases yeah... | 13:54 |
| dviroel | ack | 13:54 |
| sean-k-mooney | well i was more thinkin ghtat it would not be automatic | 13:54 |
| sean-k-mooney | we would call the help in the test when we wanted it to sync them | 13:55 |
| sean-k-mooney | if we dont wnat that in teh test just set the values driectly | 13:55 |
| dviroel | yeah | 13:55 |
| sean-k-mooney | anyway we can likely move on | 13:55 |
| dviroel | i think that we will agree on an approach.. | 13:55 |
| dviroel | #topic Reviews | 13:55 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/1014459 | 13:55 |
| dviroel | "fix for memory leak on openstacksdk connections" | 13:55 |
| amoralej | morenod found bug https://bugs.launchpad.net/watcher/+bug/2173078 | 13:56 |
| sean-k-mooney | ... | 13:56 |
| amoralej | which is a pretty big memory leak related to how connections are created | 13:56 |
| sean-k-mooney | you realise this should have been treaded as a security bug | 13:56 |
| sean-k-mooney | privately | 13:56 |
| amoralej | we didn't triage that, bth, i'd set to high at least | 13:56 |
| amoralej | i didn't | 13:57 |
| sean-k-mooney | a memory leak is a denial of service vector | 13:57 |
| amoralej | ok | 13:57 |
| amoralej | good to know ... | 13:57 |
| dviroel | is this a openstacksdk only issue? | 13:57 |
| amoralej | i'd say so | 13:58 |
| amoralej | yes, not in the old clients implementation | 13:58 |
| sean-k-mooney | so this looks like we are not release the client instnace | 13:58 |
| sean-k-mooney | the copying of the model is expected in the desciosn engin case | 13:58 |
| amoralej | yes, we are not releasing and connections remain in memory | 13:59 |
| sean-k-mooney | i..e when the collector or an audit runs we create a copy of the model | 13:59 |
| amoralej | yep | 13:59 |
| sean-k-mooney | normally | 13:59 |
| sean-k-mooney | this can oly happen if we are maintining a refence to the client | 13:59 |
| amoralej | actually, before this patch, memory usage grows linearly on periodic collections, i.e. | 14:00 |
| sean-k-mooney | adn if we have created a cirular refnece | 14:00 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!