Project Sponsor
Name: Kushal Das
Fedora Account Name: kushal
Infrastructure Sponsor: N/A
Secondary Contact info
Name: Sayan Chowdhury Fedora Account Name: sayanchowdhury
Name: Ratnadeep Debnath Fedora Account Name: rtnpro
Name: Praveen Kumar Fedora Account Name: kumarpraveen
Project Name: Autocloud
Target Audience: Fedora Releae engineering, Fedora Cloud working group
Expiration/Delivery Date (required): 29th September
Description/Summary:
Autocloud is the system to automatically test Fedora atomic and cloud images built on koji. It will also test vagrant images. https://fedoraproject.org/wiki/Changes/Two_Week_Atomic contains the design of the grand idea. http://autocloud.readthedocs.org/en/latest/setup.html contains the whole setup instructions for Fedora.
We have some other services (fedora-packages, pagure) that use redis for various things, but they have their redis config crammed into their app-specific roles. We should use this as an opportunity to break that out into an independent 'redis' role that we can more effectively audit in the future.
Is everything for this packaged for EPEL7?
I guess I don't understand what would need to go into the VirtualBox backend component, but I imagine that will be a sticking point. If it is problematic, can we set up everything but that component to try things out in the meantime? Or, is it essential?
Other than any issues there, it looks like the setup here will be a relatively straightforward copy of some of our other fedmsg-driven frontend/backend paired systems.
Replying to [comment:1 ralph]:
We have some other services (fedora-packages, pagure) that use redis for various things, but they have their redis config crammed into their app-specific roles. We should use this as an opportunity to break that out into an independent 'redis' role that we can more effectively audit in the future. Is everything for this packaged for EPEL7? We are thinking about deploying on Fedora, as we will be dealing with latest qcow2/3 images, and Virutualbox, and vagrant. The only way to using these without trouble is actually using Fedora instead of EL. I guess I don't understand what would need to go into the VirtualBox backend component, but I imagine that will be a sticking point. If it is problematic, can we set up everything but that component to try things out in the meantime? Or, is it essential?
Is everything for this packaged for EPEL7? We are thinking about deploying on Fedora, as we will be dealing with latest qcow2/3 images, and Virutualbox, and vagrant. The only way to using these without trouble is actually using Fedora instead of EL.
It is essential. We just have to change one config value in that system to test the virtualbox images. This also means we have to be careful in upgrading kernels in that box.
Other than any issues there, it looks like the setup here will be a relatively straightforward copy of some of our other fedmsg-driven frontend/backend paired systems. Thats good. Thanks for the comments :)
Suggesting critical priority since this is key to a F23 change the team is still trying to land for GA if possible.
Note that I began creating the web nodes today but got sucked into other work.
I won't be able to create the backend nodes, since they require hardware, correct?
Would VMs be okay for the staging backend nodes, but hardware for the prod ones?
A while back we were talking about nested virt and I indicated I had tried it a while back and it didnt work at all. However, I just tried again with rhel7 and it seems to actually work now.
So, we could try the backend instances (or one of them) as a vm and see if we can get nested virt working? Happy to work with you on that if you would like.
OK, I created preliminary config and instances:
... and I'm creating the db now. The password will be kept in the private repo and will be available as the autocloud_db_password and autocloud_db_password_stg ansible vars.
The frontend nodes are rhel7, and the backend nodes are Fedora 21. They're all VMs. If it turns out we need hardware for the production backend nodes, we can probably do that, but there's hopefully plenty of config work that can be done in the meantime on the staging VMs (set up the app, set up the schema for the db, configure haproxy, set up nagios checks, set up collectd monitoring, etc..)
Do hit us up so we can help you set up the app. (start by looking at existing roles in the ansible repo, etc..)
OK, I set up all the configuration for both the frontend and the backend here: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/autocloud
The webapp is available at https://apps.fedoraproject.org/autocloud
Everything should be working except for autocloud-backend02, which does the virtualbox stuff. We have it in place in a VM, but apparently it needs hardware. That's the last TODO item.
We have to add /etc/hosts entry
koji.fedoraproject.org
Our consumer failed in the morning for the same. For now I have added them manually.
Just now realized that we have to add hosts entry for fedorapeople too as tunir automatically downloads the tests from there (kushal.fedorapeople.org) in the vms. The atomic tests will also require to get docker images from docker hub, there is a cloud base image test which installs a package using dnf. I don't know if we should keeping each host manually or not.
This is done now. Thanks to smooge, puiterwijk and all who helped out!
Login to comment on this ticket.