RHINENG-4700_and_5552: Use deletion for culling and rename attributes in custom staleness

[thearifismail]

Overview

This PR is being created to address RHINENG-4700 and RHINENG-5552 and replace the PR #1550

PR Checklist

• Keep PR title short, ideally under 72 characters
• Descriptive comments provided in complex code blocks
• Tests: validate optimal/expected output
• Tests: validate exceptions and failure scenarios
• Tests: edge cases
• Recovers or fails gracefully during potential resource outages (e.g. DB, Kafka)
• Uses type hinting, if convenient
• Documentation, if this PR changes the way other services interact with host inventory
• Links to related PRs

Secure Coding Practices Documentation Reference

You can find documentation on this checklist here.

Secure Coding Checklist

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

[fellipeh]

How this will work with the current databases? I saw the changes on migrations folder only for the fields name creation..,

[thearifismail]

How this will work with the current databases? I saw the changes on migrations folder only for the fields name creation..,

After making these changes, I successfully ran the make task make upgrade_db followed by pytest.

[fellipeh]

lgtm

[fstavela]

How this will work with the current databases? I saw the changes on migrations folder only for the fields name creation..,

After making these changes, I successfully ran the make task make upgrade_db followed by pytest.

Did you run the DB upgrade on an already existing database or on a new one? This change to the DB migration is my only concern with this PR, I think the proper way would be to create a new migration instead of updating an existing one. I don't know if this approach will work on existing databases in Stage and Prod. But I've never done this, so correct me if I'm wrong.

Otherwise, the PR looks good.

[thearifismail]

How this will work with the current databases? I saw the changes on migrations folder only for the fields name creation..,

After making these changes, I successfully ran the make task make upgrade_db followed by pytest.

Did you run the DB upgrade on an already existing database or on a new one? This change to the DB migration is my only concern with this PR, I think the proper way would be to create a new migration instead of updating an existing one. I don't know if this approach will work on existing databases in Stage and Prod. But I've never done this, so correct me if I'm wrong.

Otherwise, the PR looks good.

Thank you @fstavela; very good point. I ran it on a new DB but let me run against an older one, i.e. migration.

[kruai]

+1 to the point about the migrations - you'll need to make a new migration rather than modify the existing ones.
Also, there are a few places where the field names haven't been updated, and it would make sense to update them all at once.

[kruai]

We might as well update the field names in the config file and environment variables too; it'll be confusing if we don't.

[thearifismail]

Done!!!

[thearifismail]

+1 to the point about the migrations - you'll need to make a new migration rather than modify the existing ones. Also, there are a few places where the field names haven't been updated, and it would make sense to update them all at once.

hmmm... I did bulk find and resplace. Let me look. Thanks.
oh you mean the config's attributes' names. like conventional_time_to_stale": config.conventional_staleness_seconds

[jpramos123]

LGTM!

Thanks for this PR.

the _time_to was a good approach to solve the variables naming we discussed!!