[Audit] Add audit to more Katello resources - Content-view, Repository, Lifecycle environment and their associations
#3 Updated by Kavita Gaikwad over 1 year ago
- Subject changed from [Audit] Content view - creation, publish (?), destroy (Composite & Non-composite) to [Audit] Add audit to more Katello resources - Content-view, Repository, Lifecycle environment and their associations
activation-key don't record any log if a user assign/unassign a host collection to/from it
- Enabled repositories:
This would just show up as a repo create.
Note: based on this, we may not be able to differentiate between a custom repo create and a RH repo
enablement. but important is we have data, later we can better display them, e.g. enabled vs created...
- Lifecycle environment + associations
Note: there are a lot of possible associations for environments; however, not sure if it makes sense to
audit all of them.
Katello::KTEnvironment - for basic CRUD
capsule_lifecycle_environments (association) - add/remove capsules
Yeah, we'd need a lot more information here. seeing that:
What LE a host is assigned to (hosts (association)) - this should probably be audited on host side? should
we start auditing hosts' subscription facets?. It looks like this one would be on the content_facet, but it
does seem worthy to audit. On the subscription facet side, wonder if it would be useful to include when a
pool is added/removed to the host.
What Content View Version is in a particular environment (content_view_versions (association)) similar
to above but with content facet
- (Composite) Content view - creation, publish (?), destroy
Katello::ContentView - for basic CRUD
For composite views:
content_view_components (association) - add/remove component (i.e. Composite Content View
For non-composite (or component views):
repositories (association) - add/remove repository
content_view_puppet_modules (association) - add/remove puppet-module
filters (association) - CRUD (Katello::ContentViewFilter)
repositories (association) - add/remove repositories
Note: Each of the *Filter models below have a STI relationship with
docker_rules (association) - CRUD rules
erratum_rules (association) - CRUD rules
package_rules (association) - CRUD rules
package_group_rules (association) - CRUD rules
Katello::ContentViewVersion - CRUD actions should handle the CV publish (and possibly promote &
- Custom repository
Katello::Repository - CRUD
The requirement mentions 'knowing when custom repos are added to the satellite', I assume this would
be via basic create actions on the Repository model. That said, the same model is used for both custom
and RH repos.
The requirement mentions 'which are added to Content views', I assume this can be done with the
'repositories' association on the ContentView model above.
- Incremental updates of content (rpm and puppet)
this would be handled the same way as a Content View Version above, publish/promote butwould need investigation. Might be able to differentiate with a comment.