Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: New Events are required for Control Policy and Compliance Policy: Container Node Discovered Container Project Discovered Container Pod Discovered Container Discovered Image Registry Discovered Container Project Compliance Check, Failed and Passed Container Compliance Check, Failed and Passed Image Registry Compliance Check, Failed and Passed Container Node Analysis Request, complete Container Project Analysis Request, complete Container Pod Analysis Request, complete Container Analysis Request, complete Image Registry Analysis Request, complete
Please assess the impact of this issue and update the severity accordingly. Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition. If it's something like a tracker bug where it doesn't matter, please set the severity to Low.
we should add also: Volumes Services Builds
(In reply to Loic Avenel from comment #0) > Description of problem: New Events are required for Control Policy and > Compliance Policy: > > Container Node Discovered > Container Project Discovered Beni, Mooli, how hard is to add these two ones (similar to what we do in Images discovery for OpenSCAP)?
(In reply to Federico Simoncelli from comment #5) > (In reply to Loic Avenel from comment #0) > > Description of problem: New Events are required for Control Policy and > > Compliance Policy: > > > > Container Node Discovered > > Container Project Discovered > > Beni, Mooli, how hard is to add these two ones (similar to what we do in > Images discovery for OpenSCAP)? Sorry it was (Projects and Pods, not Node): > Container Project Discovered > Container Pod Discovered
Discovered events are easy to code - same approach as image discovered - but they have some refresh performance price. We already had concerns about the image discovered policy lookups causing significant portion of DB queries during refresh (which also makes it more DB latency sensitive). cc Ladislav. Ideas: - measure! add pod discovered, see how much it costs. - graph refresh queues raising these events for later, which should allow perf impact to be absorbed by scaling up generic workers, so IMO this is acceptable. - add setting to disable these events? - [larger scope] optimize policies, at least fast path when no policies apply to an event type.
Beni: I would probably just add the inventory based events to graph refresh post processing. Queuing them in batches, like we do for images, has minimal impact on the refresh worker. (at some point we need to stop developing for the old refresh anyway :-)) Settings for disabling these events make sense, since there is quite an overhead to process each event, even when there is no Automate behavior tied to it. (not sure how to optimize the policies, that could be a way too)
Inventory Events: +1 for the batched approach (see container_manager/refresher_mixin.rb) Also +1 for the setting to disable, that one might be needed systems wide and not only containers Compliance check passed and failed: the events should be as simple as just adding them BUT I think that would also require adding those object types mentioned(container project, container, image registry, volume, container services & builds) to the SUPPORTED_POLICY_AND_ALERT_CLASSES in miq_alert (as well as some minor ui work for the control explorer) Analysis Request, complete: I'm not sure how analysis is relevant for objects other then container image?