-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add adr0001 - why project pravic? #12
Add adr0001 - why project pravic? #12
Conversation
Build failed. ✔️ build-ansible-collection SUCCESS in 3m 44s |
|
||
In the above example, the VPC must be created before any other resources and the security group must be created before the instance and the elastic cache. We could identify this both through the resource references in the resource definition and by analyzing the AWS schemas for these resources. | ||
|
||
### Asynchronous Execution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this section could be a bit clearer. It switches back and forth between talking about Ansible's async execution and pravic's async execution. They're both useful, but the main selling point with pravic is that the playbook author doesn't need to think about it. Asynchronous execution isn't a playbook level feature, it's just built directly into the collection.
Build failed. ✔️ build-ansible-collection SUCCESS in 3m 33s |
recheck |
Build succeeded. ✔️ build-ansible-collection SUCCESS in 3m 29s |
I think I understand the use case and I want to share how I create infrastructure with ansible (sometimes), in case it could give you ideas. TL;DR: I create myself a role or playbook and then use that as an interface to the various modules. I wouldn't really say it's declarative (I'm not interested in arguing about that) but you could say the imperative part is mostly hidden away behind an abstraction layer: the role or playbook :p I can supply these the necessary vars (what image, ssh key, firewall rules, or virtual networks, etc) in a lot of ways, from the inventory, as extra vars or a vars file that looks like the example from this PR under For an example playbook that creates things on digitalocean where I also end up adding the host to the inventory such that I can deploy on top of it once it's up and available: https://github.com/ansible-community/ara-infra/blob/5bf45600148e7dfa8e1c92f801a71a0ddb9157fc/playbooks/digitalocean_infra.yaml#L78-L83 For a role example, I have an (unfortunately closed source) role called I have some sane defaults set up in role variables such that I don't need to specify everything and some are omitted if not provided but you get the idea. I say this because Collections can ship roles and playbooks now, not only modules and plugins. They could be used as abstraction layers to manage infrastructure a bit like this ¯\(ツ)/¯ In other words, there could be an I don't have all the answers, it wouldn't be the fastest and it probably doesn't tick all of the boxes but could be an interesting approach, perhaps. Of course, I like the regular ansible approach because then I have reporting on every individual playbook, host and task with ara :p |
@dmsimard I understand where you're coming from for the use case of VMs, but public cloud is so incredibly vast we can't even keep up with modules let alone create and support roles for everything our users do on public cloud. Generated collections have been explored by both Ansible and GCP and this helps, but it's still an ongoing game of catch-up. Abstracting resources in this way, rather than creating a single module for every resource on every hyperscaler, gives users a more direct and faster way to use new resource types as they're made available on the hyperscaler's resource management API. Unfortunately it's really not feasible or us to make roles for everything. We just don't have nearly enough people (combined in the community and Ansible eng) to attempt something like this for even one hyperscaler for enough resources to be broadly useful. |
recheck |
Build succeeded. ✔️ build-ansible-collection SUCCESS in 6m 47s |
Build succeeded (gate pipeline). ✔️ build-ansible-collection SUCCESS in 6m 55s |
Pull request merge failed: Resource not accessible by integration, You may need to manually rebase your PR and retry. |
Add an architectural decision record with the rational behind the project
Co-authored-by: Mike Graves <mgraves@redhat.com>
Co-authored-by: Mike Graves <mgraves@redhat.com>
Build succeeded. ✔️ build-ansible-collection SUCCESS in 6m 59s |
Build succeeded (gate pipeline). ✔️ build-ansible-collection SUCCESS in 6m 47s |
SUMMARY
Initialize ADR directory
Add an architectural decision record with the rational behind the project
ISSUE TYPE
COMPONENT NAME
adr
ADDITIONAL INFORMATION
This ADR should be circulated widely to the community before merging