On Wednesday, October 20, 2021 6:44:20 PM CET Kevin Fenzi wrote: > Greetings. > > Mark and I have talked in the past about moving some of the aws > provisioning we are doing into ansible, and it came up again this > morning in #fedora-admin. > > We have many (but not all) maintainer-test instances, a bunch of proxies > and all the copr machines in aws that are currently in ansible. > > I think we could do something similar to tasks/virt_instance_create.yml > (which we have for using virt-install and installing libvirt vms). > We do have a tasks/aws_cloud.yml that copr instances use, but it doesn't > provision the instance, just sets up things for ansible. Yeah, I was in particular lazy to teach the playbook to start the machines. We instead just documented the steps in for us for now: https://docs.pagure.org/copr.copr/how_to_upgrade_persistent_instances.html But we already worked with starting builder AWS machines via playbooks: https://pagure.io/fedora-infra/ansible/blob/0fb047d8ad3d9fa3a2d4d5c7c175c4282694ba47/f/roles/copr/backend/files/provision/builderpb-aws-spot-x86_64.yml#_13-26 ... points to: https://pagure.io/fedora-infra/ansible/blob/0fb047d8ad3d9fa3a2d4d5c7c175c4282694ba47/f/roles/copr/backend/files/provision/spinup_aws_task.yml Something like that could be reused. We don't use this anymore, now we use scripts from https://github.com/praiskup/resalloc-aws/tree/main/bin . That's because we already start _many_ other types of VMs, and that "ansible ec2 module" approach was too different from others. Plus, from time to time, the playbook failed, and it caused headaches to us (we start thousands of VMs, and we need to have the boot up process robotized, and 100% under control). This wouldn't be a blocker for the infra machines (contrary to the builder playbooks, the infra playbooks execution is under a _human_ control). > Copr folks: if we expand aws_cloud.yml to provision also (if the host is > not up/reachable on it's dns name/ip) would you be ok using that as > well? Or should we seperate out copr from maintainer-test/proxies? Definitely, it would simplify our life. Actually, very soon we'll have to migrate our servers from F33 to F35 so we would benefit from this change. > Also, there's the question of auth. batcave01 will need creds for those > things. Sadly, I think this means making a user and getting a token, but > if there's some better way to handle auth there that might be nice. Meh, yeah. Though except that we need to create a new user in AWS for batcave, I don't think it is too risky or hard to implement (can be configured in private git, in vars file). The VMs started using this "token" would be easily traceable I think. Pavel > Finally, we are using ansible-2.9.x currently. We would need any > solution to be able to work with that and newer ansible, which we likely > will be switching to before long. > > Any other ideas or thoughts around this? > > Thanks, > > kevin > _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
