Add provisioning via automation manager such as terraform enterprise #772
Conversation
…nfra vm provisioning
jrafanie
force-pushed
the
add-provision-via-terraform-enterprise
branch
from
4ff0b64 to
37d5257
Compare
| - Relationship5: | ||
| value: "/AutomationManagement/AutomationManager/Provisioning/Profile/${/#user.normalized_ldap_group}#get_state_machine" | ||
| - Relationship6: | ||
| value: "/AutomationManagement/AutomationManager/Provisioning/StateMachines/${/#state_machine}/default" |
There was a problem hiding this comment.
Note, we can remove a lot of indirection here if we don't care about getting a per ldap group state machine... we could go directly to:
"/AutomationManagement/AutomationManager/Provisioning/StateMachines/Provision/default"
There was a problem hiding this comment.
We can add it later if needed.
There was a problem hiding this comment.
By the way, this came from vm and physical server provisioning. I mapped out the flow and both went through Provisioning/Profile to get a state machine that would be used to route to the correct Statemachines/Provision.
/Infrastructure/VM/Lifecycle/Provisioning
/Infrastructure/VM/Provisioning/Profile/${/#user.normalized_ldap_group}#get_state_machine
/Infrastructure/VM/Provisioning/Profile/.missing
state_machine: VMProvision_${/#miq_provision.target_type}
/Infrastructure/VM/Provisioning/StateMachines/${/#state_machine}/${/#miq_provision.provision_type} =>
/Infrastructure/VM/Provisioning/StateMachines/VMProvision_VM/Provision VM from template
CustomizeRequest...
AcquireIPAddress...
Provision: /Infrastructure/VM/Provisioning/StateMachines/Methods/Provision
$evm.root["miq_provision"].execute
/PhysicalInfrastructure/PhysicalServer/Lifecycle/Provisioning
/PhysicalInfrastructure/PhysicalServer/Provisioning/Profile/${/#user.normalized_ldap_group}#get_state_machine
PhysicalInfrastructure/PhysicalServer/Provisioning/Profile/.missing
state_machine: Provision
/PhysicalInfrastructure/PhysicalServer/Provisioning/StateMachines/${/#state_machine}/default
/PhysicalInfrastructure/PhysicalServer/Provisioning/StateMachines/Provision/default
Provision: /PhysicalInfrastructure/PhysicalServer/Provisioning/StateMachines/Methods/Provision#${/#physical_server_provision_task.source.emstype}
/PhysicalInfrastructure/PhysicalServer/Provisioning/StateMachines/Methods/Provision#lenovo_ph_infra
$evm.root["miq_provision"].execute
I added it for automate manager:
/AutomationManagement/AutomationManager/Lifecycle/provisioning.yaml
/AutomationManagement/AutomationManager/Provisioning/Profile/${/#user.normalized_ldap_group}#get_state_machine
/AutomationManagement/AutomationManager/Provisioning/Profile/__class__.yaml
state_machine: Provision
/AutomationManagement/AutomationManager/Provisioning/StateMachines/${/#state_machine}/default =>
/AutomationManagement/AutomationManager/Provisioning/StateMachines/Provision/default
CustomizeRequest...
AcquireIPAddress...
Provision: /AutomationManagement/AutomationManager/Provisioning/StateMachines/Methods/Provision
$evm.root["miq_provision"].execute
It could be as simple as:
/AutomationManagement/AutomationManager/Lifecycle/provisioning.yaml
/AutomationManagement/AutomationManager/Provisioning/StateMachines/Provision/default
CustomizeRequest...
AcquireIPAddress...
Provision: /AutomationManagement/AutomationManager/Provisioning/StateMachines/Methods/Provision
$evm.root["miq_provision"].execute
There was a problem hiding this comment.
As discussed the per-ldap thing allows the user to split off different state machines by ldap group. I don't think required for the new section in automate, but we may want it there for consistency. Personally, I'd leave it out for now.
There was a problem hiding this comment.
I'll leave it here for now for consistency.
| schema: | ||
| - field: | ||
| aetype: attribute | ||
| name: state_machine |
There was a problem hiding this comment.
This whole file could go away if we don't care about per ldap group statemachines...
| --- | ||
| object_type: instance | ||
| version: 1.0 | ||
| object: |
There was a problem hiding this comment.
Everything in Provisioning/Profile.class would all go away if we don't care about per ldap group statemachines...
Drop CheckProvisioned as we'll do it in ruby/workflow
jrafanie
force-pushed
the
add-provision-via-terraform-enterprise
branch
from
37d5257 to
87d9164
Compare
| datatype: string | ||
| priority: 9 | ||
| owner: | ||
| default_value: "/AutomationManagement/AutomationManager/Provisioning/StateMachines/Methods/Provision" |
There was a problem hiding this comment.
@Fryguy and I discussed this and think for terraform enterprise, we don't need the check provisioned because the workflow ruby code implements this and will wait until it's finished running before signaling post provision. For other providers moving into this generic bucket, we may need to have the existing check provisioned in automate do this. Thoughts @agrare ?
There was a problem hiding this comment.
Really what it comes down to is: do all the providers provision synchronously such that at the end the refresh has completed and the new object has come back into the database. if so, and if we declare that's the required interface, then I don't think we need CheckProvisioned step on the automate side.
There was a problem hiding this comment.
We can add check provisioned step later if needed it.
|
Reviewed all the PRs live with Joe - they all seems to going in the right direction IMO, and he posted comments for things we discovered in the call. |
|
Dropping wip on this. I think it's fine to leave things as is and revisit it if needed. |
jrafanie
changed the title
2 participants
Merge with:
Generic automation manager provisioning logic and modeling:
Terraform provisioning