Hi @bking. Thanks for the task! Do note that regardless of the task above, PyBal will soon be deprecated in favour of Liberica, once T368544 is resolved, which should happen within a few quarters.

I am just mentioning this so that we can factor the above in before doing any more work or investing engineering time on PyBal since the plan is to deprecate it soon. (Only eqiad and codfw have PyBal running and while that's significant, the only blocker is k8s stuff, otherwise we would have switched to Liberica there. We are intentionally not rolling out both Liberica and PyBal to keep things uniform.)

Thanks @ssingh , that's completely understandable. If PyBal is going away, it's probably not worth the effort to fix it.

But I'm wondering if Liberica has the same issue? In other words, is it possible to create an invalid Liberica config via Puppet patches, that would be caught by the ConfdResourceFailed alerts? If so, then the task is still valid, it just needs to change scope. Let me know what you think.

In T394789#11229562, @bking wrote:

Thanks @ssingh , that's completely understandable. If PyBal is going away, it's probably not worth the effort to fix it.

But I'm wondering if Liberica has the same issue? In other words, is it possible to create an invalid Liberica config via Puppet patches, that would be caught by the ConfdResourceFailed alerts? If so, then the task is still valid, it just needs to change scope. Let me know what you think.

I think that depends on which Liberica config -- Liberica will still refer to the service definitions under hieradata/common/service.yaml and read those (see modules/liberica/functions/service_from_wmflib.pp) and then there is a CI check that tries to compile the catalog (see modules/profile/spec/classes/profile_liberica_spec.rb), so it certainly has more guard rails than PyBal.

Can you remind me what the invalid configuration was in this case? That way we can compare it against the Liberica checks to see if they would have been caught.