I think you may be misunderstanding me, or I'm misunderstanding you. Just for clarity's sake, the flow you would like is:
1. An Ansible control node runs a playbook (or role) on <controlnode> targeting a machine, <targetmachine> 2. The <targetmachine> is configured to run as a Vagrant host with a virtualisation provider (Virtualbox, Libvirt or whatever) in order to support Vagrant box creation 3. You then have a Vagrantfile which runs on <targetmachine> and configures multiple Vagrant boxes <vb1>, <vb2>, <vb3> 4. Once <vb1>, <vb2>, <vb3> are UP* and only then,* you want to run some Ansible which needs the primary and 2 secondaries to be up That being the case, then that is the behaviour that https://developer.hashicorp.com/vagrant/docs/provisioning/ansible#ansible-parallel-execution describes. It's slightly poorly worded but to me: # Only execute once the Ansible provisioner, # when all the machines are up and ready. Is equivalent to: # Provision all Vagrant boxes in the multi-machine setup. # Only once all the machines are up and ready, run the Ansible provisioner If that's not what's happening, that's likely a Vagrant configuration or provisioner misbehaviour? That's why I'm saying this isn't necessarily an Ansible thing. That wording, the boxes should all spin up before any Vagrant Ansible provisioner runs, you're saying that's not the case. That sounds like either your Vagrantfile is wrong, or your Vagrant VM provisioner or something else isn't working as expected. I'm spinning this up on a test but if you already have a test case/reproducer, or can provide more info on your Vagrant setup then this would collectively help people help you. If there's an obvious error in your Vagrantfile it could be a simple fix rather than an edge case. cf: - https://manski.net/2016/09/vagrant-multi-machine-tutorial/#multi-machine.3A-the-clever-way - https://developer.hashicorp.com/vagrant/docs/provisioning/ansible#ansible-parallel-execution On Sat, 25 Nov 2023 at 21:55, Evan Hisey <[email protected]> wrote: > Vagrant is behaving fine, so not a vagrant specific problem. It is a task > problem. I need the vagrant hosts fully installed first because I have to > collect data from all 3 at once before deploying the software, and during > software deployment I have to install the master first, collect keys and > then install the slaves. Vagrant provider provisions does provide this kind > of control as it assumes the each provisioned VM is self contained. A more > typical solution would be to directly remote in to the VM's for ansible to > run after deployment from the remote controller, but that is not an > available option. Only the vagrant host will have access to the vagrant > vms, and really only as the vagrant user. The last limitation is not hard > to deal with, as vagrant provides everything an ansible job would need if > run from the vagrant host. > > That is why I need to trigger to a vagrant host ansible playbook, since it > can't not run from the initial ansible controller. Yes it is a bit of an > odd edge case, as the vagrant provider normally would be plenty. > > On Sat, Nov 25, 2023 at 2:08 PM Will McDonald <[email protected]> wrote: > >> It sounds like a Vagrant issue rather than an Ansible issue. Or possibly >> a niche Vagrant provider problem. >> >> Can you share a sample Vagrantfile that's not behaving as it should and >> details of the target OS of the Vagrant host, and the virtualisation >> provider you're using? >> >> >> On Sat, 25 Nov 2023 at 19:30, Evan Hisey <[email protected]> wrote: >> >>> Already tried it and it does not work, which was why I explicitly >>> referenced that behavior as not working as not working in this >>> scenario.While vagrant can run playbooks at provisioning time. it does not >>> really proivde a way to to control when the provisioin runs. All 3 hosts >>> need to be up be for the first host can be provisioned since it requires >>> the ips of the later hosts. Second option does not work, as the remote >>> control node does not have access to the VMs, as mentioned. Which is what >>> lead to the need to trigger a second playbook. otherwise could lust load >>> the vagrant generated inventory with add_host module. >>> >>> IC ould do some ugly sequencing of the "vagrant up --provision" from a >>> playbook to control the ansible provisioning sequence of the vms, but I am >>> trying to avoid using ugly shell commands as much as I can. If I uses a >>> shell command I could also just trigger an ansible playbook that way, but >>> feels wrong. >>> >>> >>> On Sat, Nov 25, 2023 at 12:40 PM Will McDonald <[email protected]> >>> wrote: >>> >>>> Quickly skimming the Vagrant Ansible provisioner docs, isn't this >>>> precisely the behaviour you're looking for: >>>> >>>> >>>> https://developer.hashicorp.com/vagrant/docs/provisioning/ansible#ansible-parallel-execution >>>> >>>> # Only execute once the Ansible provisioner, # when all the >>>> machines are up and ready. >>>> >>>> So you would spin up all your Vagrant boxes from your control node, >>>> wait for that to complete, template out a static inventory of your Vagrant >>>> boxes then run your subsequent Vagrant Ansible provisioner automation? >>>> >>>> >>>> >>>> On Sat, 25 Nov 2023 at 18:20, Evan Hisey <[email protected]> wrote: >>>> >>>>> I am working on a scenario where the first playbook executes commands >>>>> on a remote host to create a vagrant host and spins up multiple vms. >>>>> Vagrant can triggers it's own ansible provisioning runs but they are only >>>>> single host aware and run when the host is provisioned. That does not work >>>>> in this case, as I need all VM's running BEFORE the deployment playbook >>>>> can >>>>> be triggered. Added wrinkle is the VMs are accessible at this time from >>>>> outside the vagrant host. If they were, I could simply import the vagrant >>>>> host list into the controller inventory and refresh. >>>>> >>>>> Right now I am looking at the possibility of using >>>>> ansible.builtin.shell to trigger the new ansible-playbook command on the >>>>> vagrant host to run the vagrant VM application configuration. But while >>>>> this works it is not exactly ansible clean. Suggestions on approaches? >>>>> >>>>> -- >>>>> Evan Hisey >>>>> [email protected] >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ansible Project" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ansible-project/CAEcFzYwsmYmvh%3DWJwSNmJWertkxFRDiKkumnwhzAFupggP58Vg%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/ansible-project/CAEcFzYwsmYmvh%3DWJwSNmJWertkxFRDiKkumnwhzAFupggP58Vg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ansible Project" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/CAKtKohS2LdL4qtTyQF8VdV6pu2tjL3mx868TgvkwvAEUkRbF%3Dg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/ansible-project/CAKtKohS2LdL4qtTyQF8VdV6pu2tjL3mx868TgvkwvAEUkRbF%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/CAEcFzYxdk%3DfA13__d1wEJTiTkpDnaR2eqEpGm%2BXy3v3L1M%3DJ9A%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/CAEcFzYxdk%3DfA13__d1wEJTiTkpDnaR2eqEpGm%2BXy3v3L1M%3DJ9A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CAKtKohQ8PP4n7h-ERfE4iONYxZK-nZRLaoMwvRATzSj1hnD%3Dbw%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CAKtKohQ8PP4n7h-ERfE4iONYxZK-nZRLaoMwvRATzSj1hnD%3Dbw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAEcFzYwxGLhF275kMbBaMMUx6FNQoduaxO7wa_j9AVkUw5ZQVg%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CAEcFzYwxGLhF275kMbBaMMUx6FNQoduaxO7wa_j9AVkUw5ZQVg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAKtKohS9rcVZ0rOe_MH9bdb2EgFL7jeBmqwLgyRbZMG2NjmrmQ%40mail.gmail.com.
