Tenant scoped automation domains

Hi Guys,

I want to implement tenant scoped automation domains and I need to understand where this will lead.

If I use top level automation domain I can create Event Handlers and Aporoval state machine for enire organization, but If user create tenant own automation domain it can override top level handlers and Approval state machine ?

Interesting question.

I’d expect your tenant automate domain to take priority whenever $evm.root['tenant'] matched the tenant that you’d created the domain for, so mainly for user-initiated workflows.

Try calling object_walker from any of the approval policy instances and see what tenant context it’s running in.


1 Like

Hi @pemcg

I have one top organizational-level tenant and too many second-level tenants synced from OpenStack.

Primarily I am interested in system tasks implemented with the help of Automation. The System namespace have classes such as event_handlers and Policy Event. The Child Tenants can have its own automation domains and I want to understand the impact of this child-tenant-automation domain to system task such as Event Handler for events from external management system. I use OpenStack and I use events for integration purposes (compute.instance.create.end event trigger workflow DNS registration for newly created instances)

For Approval and Quota SM I have the same question. Can child-tenant-automation domain override these SMs and methods for this task ? If it is I cannot enforce quotas to child tenants because child-tenant-automation domain can just disable quotas and approvals workflows.

I’m pretty sure event handlers would be processed as the ‘admin’ user, so in the context of tenant zero, but object_walker or InspectMe would confirm this.

1 Like

Hi @pemcg

During memory issue investigation I found that messages have tenant_id attribute and this may shed light on the process of message processing:

    [----] I, [2017-09-07T10:34:09.019774 #31077:1119134]  INFO -- : MIQ(MiqPriorityWorker::Runner#get_message_via_drb) Message id: [14795640], MiqWorker id: [2014775], Zone: [], Role: [automate], Server: [], Ident: [generic], Target id: [], Instance id: [], Task id: [], Command: [MiqAeEngine.deliver], Timeout: [3600], Priority: [20], State: [dequeue], Deliver On: [], Data: [],
        {:object_type=>"MiqServer", :object_id=>2, 
            :event_details=>"Worker [ManageIQ::Providers::Openstack::CloudManager::MetricsCollectorWorker] with ID: [2042408], PID: [3192], GUID: [e2f61410-939e-11e7-941c-0050568e42e5] process memory usage [1172726000] exceeded limit [419430400], requesting worker to exit",
    Dequeued in: [1.179016969] seconds

Is this attribute taken into account when choosing an automation domain?