Hey Todd,
Thanks for the reply. To answer your questions: 1. I went with that particular structure mostly due to some previous attempts at this setup, the plan would be 1 customer per file. The `customer_name` portion could certainly be omitted. 2. Each *_server entry was intended to represent a single server in this example, not a group. 3. The other reason I included the customer_name portion at the top was as a simple way to differentiate which server the customer belongs to (since I am using dynamic inventory). I also have a tag and matching keyed group, so I could certainly use that instead. So based on your recommendations and to avoid confusion: # example.yml database_server_01: down_group: 3 up_group: 1 vcenter: vcenter.local exclude: false database_server_02: down_group: 3 up_group: 2 vcenter: vcenter.local exclude: false file_server_01: down_group: 2 up_group: 3 vcenter: vcenter.local exclude: false print_server_01: down_group: 1 up_group: 2 vcenter: vcenter.local exclude: false The order is unfortunately not as simple as *groups* of servers, but rather each server individually has a specific “power up” or “power down” group. An unfortunate holdover from an archaic software that also prevents me from simply using a reboot or win_reboot command to handle this more cleanly. On Wednesday, August 17, 2022 at 9:40:43 PM UTC-5 [email protected] wrote: > First, let's get some text instead of pixels. You've got > > --- > # example.yml > customer_name: > database_server: > - down_group: 3 > - up_group: 1 > - vcenter: vcenter.local > - exclude: false > file_server: > - down_group: 2 > - up_group: 3 > - vcenter: vcenter.local > - exclude: false > print_server: > - down_group: 1 > - up_group: 2 > - vcenter: vcenter.local > - exclude: false > > Is "customer_name" a placeholder for things like "AcmeCo", and are there > more sections similar to this for other customers in the same file, or are > they in different files? > > I take it for this example you want to down the servers in > ("print_server", "file_server", "database_ server") order, then bring them > back up in ("database_server", "print_server", "file_server") order? > > I'm curious why you've got each of your "server types" composed of a list > of single entry dicts rather than simply dicts. (It would look exactly the > same as above, but without the dashes.) Is that data design attractive for > other reasons, and would you be willing to rework it if some other > structure proved more practical? > > On Wednesday, August 17, 2022 at 7:43:49 PM UTC-4 [email protected] > wrote: > >> So this is a pretty specific case but I am pretty lost on the best way to >> approach it. Hopefully the hive mind can give me some guidance here. >> >> I work for an MSP and each customer has specific reboot order >> requirements due to the specific applications we host for them. >> >> For instance; >> [image: example.yml — ccif-patching-playbooks_Code_20220817_183542.png] >> >> I have the above .yml variable file that defines the groups for each >> customer. It then applies those groups as tags on each server in vCenter. >> [image: vSphere - Summary_Google Chrome_20220817_183728.png] >> >> This allows servers to be placed in keyed groups using the VMware dynamic >> inventory plugin. So that's all working fantastic. >> >> My problem now is the best way to go about making sure the tasks that >> need to be run the on the servers (for example, a reboot), are executed >> precisely in the order of that group. Of course, I could manually specify >> that, but at the scale (think thousands of servers) with dozens of groups, >> is not practical. >> >> Does anyone have recommendations on the best way to approach this? I'd >> like it to be scalable to multiple different customers with different >> grouping requirements without having to manually specify this that would be >> most ideal. >> >> Thanks in advance and let me know if you need any additional information. >> > -- 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/5c9a9501-6972-46e9-b8ae-2ca6462df950n%40googlegroups.com.
