Comments (15)
Hi @jcpowermac,
I totally agree that the project needs reorganization.
From my POV this project has 2 main purposes:
-
Verify that Kubevirt is installable and usable on Kubernetes and Openshift using
kubevirt.yaml
and
Ansible. I would be happy to consume an unstable release ofkubevirt.yaml
every time Kubevirt's
containers are built, but we should discuss it with @fabiand . The playbook for installing Kubevirt
on Openshift will also be the basis for an APB (Ansible playbook bundle). If we can create a unified
playbook for Kubevirt deployment on Kubernetes and Openshift, it will be the best. Note that the
deployment of Kubernetes/Openshift should be added to a different playbook. -
Provide a way for developers to check their patches by building and deploying Kubvirt's containers
on Kubernetes and Openshift. In this flow, the containers will be built locally and will not be
consumed from an external registry.
I think that the best way to get forward with this task will be to add to this thread a sketch of the directory/file tree that you are thinking about.
from kubevirt-ansible.
@jcpowermac Hi I would like to move on with this issue.
I would like to join this effort with some clean up work as well.
As far as I understand to first suggestion, you want to following transformation
. .
├── ansible.cfg ├── ansible.cfg
├── automation ├── automation
│ ├── check-patch.mounts │ ├── check-patch.mounts
│ ├── check-patch.packages │ ├── check-patch.packages
│ ├── check-patch.repos │ ├── check-patch.repos
│ ├── check-patch.sh -> run.sh │ ├── check-patch.sh -> run.sh
│ ├── check-patch.yaml │ ├── check-patch.yaml
│ └── run.sh │ └── run.sh
├── common ├── config.yml
│ ├── files ├── inventories
│ │ └── keys │ └── inventory
│ │ └── README ├── LagoInitFile.yml
│ ├── roles ├── LICENSE
│ │ └── kubevirt ├── playbooks
│ │ ├── tasks │ ├── deploy-kubernetes.yml
│ │ │ └── main.yml │ ├── deploy-openshift.yml
│ │ └── templates │ ├── deploy-with-lago.yml
│ │ └── config-local.j2 │ ├── install-kubevirt-dev.yml
│ └── vars │ └── install-kubevirt-release.yml
│ └── default_vars.yml ├── README.md
├── config.yml ├── requirements.yml
├── deploy-kubernetes.yml ├── roles
├── deploy-openshift.yml │ ├── k8s-common
├── deploy-with-lago.yml │ │ ├── files
├── install-kubevirt-dev.yml │ │ │ └── 09-kubeadm.conf
├── install-kubevirt-release.yml │ │ ├── tasks
├── inventory │ │ │ └── main.yml
├── kubernetes │ │ └── vars
│ ├── roles │ │ └── main.yml
│ │ ├── deploy-kubevirt │ ├── k8s-kubevirt-install
│ │ │ ├── meta │ │ ├── meta
│ │ │ │ └── main.yml │ │ │ └── main.yml
│ │ │ ├── tasks │ │ ├── tasks
│ │ │ │ └── main.yml │ │ │ └── main.yml
│ │ │ └── vars │ │ └── vars
│ │ │ └── main.yml │ │ └── main.yml
│ │ ├── master │ ├── k8s-master
│ │ │ ├── tasks │ │ ├── tasks
│ │ │ │ └── main.yml │ │ │ └── main.yml
│ │ │ ├── templates │ │ ├── templates
│ │ │ │ └── deploy_kubernetes.j2│ │ │ └── deploy_kubernetes.j2
│ │ │ └── vars │ │ └── vars
│ │ │ └── main.yml │ │ └── main.yml
│ │ ├── node │ ├── k8s-node
│ │ │ └── tasks │ │ └── tasks
│ │ │ └── main.yml │ │ └── main.yml
│ │ └── prerequisites │ ├── kubevirt-common
│ │ ├── files │ │ ├── tasks
│ │ │ └── 09-kubeadm.conf │ │ │ └── main.yml
│ │ ├── tasks │ │ └── templates
│ │ │ └── main.yml │ │ └── config-local.j2
│ │ └── vars │ ├── ocp-common
│ │ └── main.yml │ │ ├── tasks
│ └── vars │ │ │ └── main.yml
│ └── default_vars.yml │ │ └── vars
├── LagoInitFile.yml │ │ └── main.yml
├── LICENSE │ └── ocp-kubevirt-install
├── openshift │ ├── defaults
│ └── roles │ │ └── main.yml
│ ├── kubevirt │ ├── filter_plugins
│ │ ├── defaults │ │ └── kubevirt_filters.py
│ │ │ └── main.yml │ ├── meta
│ │ ├── filter_plugins │ │ └── main.yml
│ │ │ └── kubevirt_filters.py │ └── tasks
│ │ ├── meta │ ├── main.yml
│ │ │ └── main.yml │ └── oc_obj_task.yml
│ │ └── tasks ├── Vagrantfile
│ │ ├── main.yml └── vars
│ │ └── oc_obj_task.yml ├── common
│ └── prerequisites │ └── default_vars.yml
│ ├── tasks └── k8s
│ │ └── main.yml └── default_vars.yml
│ └── vars
│ └── main.yml
├── README.md
├── requirements.yml
└── Vagrantfile
I am not sure what changes in ansible.cfg you have in mind by second point. Can you please elaborate?
from kubevirt-ansible.
Can we prioritize this? I can help if needed, I think as we prepare to get more contributions for additional projects, we have to simplify the folders structure to easy contribution.
Does it make sense to divide into subfolders like:
-
Deploy on K8S
- Deploy on existing cluster
- Deploy on VMs using Lago
- Deploy on VMs using Vagrant
- Deploy on Bare Metal
-
Deploy on OpenShift
- Deploy on existing cluster
- Deploy on VMs using Lago
- Deploy on VMs using Vagrant
- Deploy on Bare Metal
from kubevirt-ansible.
Also, this should come with an overhaul of the README file, not sure if it belongs in this issue or another one.
from kubevirt-ansible.
I think our top level directory structure should be following
- inventories/
- openshift.inv
- kubernetes.inv
- playbooks/
- deploy-cluster.yml
- install-kubevirt-release.yml
- provision-resources.yml
- control.yml (top-level-playbook)
- roles/
- all ..
- our ..
- roles we have today and new ones
- variables/ (groups-vars)
- kubernetes-1.9/
- openshift-3.9/
- masters.yml
- nodes.yml
from kubevirt-ansible.
@lukas-bednar that looks pretty good. I just want to get some clarification on the playbooks.
playbooks/
deploy-cluster.yml - deploy openshift or kubernetes cluster
install-kubevirt-release.yml - deploy kubevirt on a cluster
provision-resources.yml - ?
control.yml (top-level-playbook) - ?
from kubevirt-ansible.
@rthallisey please see inlines
playbooks/
deploy-cluster.yml - deploy openshift or kubernetes cluster
we might create one playbook per each cluster or it might depend on cluster_type
variable.
But I would probably go with cluster_type
variable because we can use it in other playbooks, for example install-kubevirt-release there are slight differences between installation on kubernetes and on openshift (SSC specifically)
install-kubevirt-release.yml - deploy kubevirt on a cluster
same as above, we can either split it into two playbooks or use cluster_type
variable
provision-resources.yml - ?
I am just giving space to Lago here, as Gal was talking about it today ...
- provide resources (vms)
- deploy cluster
- install kubevirt
control.yml (top-level-playbook) - ?
It might be playbook which will include all playbooks together to perform complete flow, according to provided parameters
from kubevirt-ansible.
playbooks/
provision-resources.yml - Provision VMs with vagrant
deploy-cluster.yml - kubernetes/openshift
install-kubevirt-resources.yml - install kubevirt on {{ cluster }}
deploy-kubevirt.yml - top-level-playbook
What do folks think? Structure looks good @lukas-bednar.
Here's a look into roles:
roles/
kubernetes
openshift
kubevirt
lago
<kubevirt-component-name>
from kubevirt-ansible.
@rthallisey yes I am good with this proposal.
In addition I would clean up repository besides this opportunity. There are roles which takes care about kubevirt compilation, I think it is not way we will go. I put this Q here #62 , and it was semi-confirmed 😄 ... so if we agree that we will not compile anything we can get of this logic.
from kubevirt-ansible.
I was talking to you about our internal repository, I can make a draft of how we organize it.
The main difference is that we have directory per each playbook. because we have collection of playbooks for different purposes, so each of them has different dependencies, different inventory file and own test. I am not sure whether we need something like this.
doc/
inventories/
playbooks/
playbook-name/
README.rst - playbook's doc
config.yml - playbook entry point (what is being executed)
requirements.yml - dependencies from ansible-galaxy
roles/ - symbolic link to roles from root directory
tests/
inventory - testing inventory file
test.yml - testing playbook built on top of docker environment
roles/ - traditional roles directory
variables/ - group vars
modules/
dockerfiles/
If you are interesting in more details about particular directories, let me know.
from kubevirt-ansible.
@lukas-bednar if we don't compile the latest resource template from kubevirt it makes it hard for kubevirt developers to want to use kubevirt-ansible. What we could do is convert the kubevirt templates into a jinja2 resource and render them from the kubevirt-ansible playbooks.
from kubevirt-ansible.
@rthallisey rendering manifest is no problem. I was referring compiling kubevirt code and building containers, and then deploying these containers on running cluster.
from kubevirt-ansible.
@lukas-bednar similar answer with regards to the kubevirt code. But instead of building the source we can use the published kubevirt images with the latest tag in addition to other releases. https://hub.docker.com/r/kubevirt/virt-controller/tags/ .
from kubevirt-ansible.
from kubevirt-ansible.
@gbenhaim @rthallisey I think we can close this one as done, unless you have objection.
from kubevirt-ansible.
Related Issues (20)
- Assertion in e2e "PVC with invalid image url" test is racy HOT 5
- Document how to contribute a new test HOT 5
- Can not spawn new containers after removing multus pods HOT 7
- 'openshift_master_default_subdomain' is undefined when run kubevirt-web-ui separately HOT 4
- kubevirt-ansible tests are running with extra namespace argument HOT 1
- Break changes in kubevirt/tests HOT 1
- OpenShift deployment broken: error: the server doesn't have a resource type "apiservices" HOT 4
- Don't disable the firewall of people which use kubevirt-ansible HOT 8
- Invalid URLs in this repo HOT 1
- Sidecar hook tests uses fc27 VMI HOT 5
- Failed to deploy multus/skydive by playbooks/network.yml due to the 'deploy_ovs_plugin' is undefined HOT 5
- The sriov-device-plugin pod keeps restarting and then goes to CrashLoopBackOff HOT 18
- Add featuregates to support 0.12 functionality HOT 2
- sriov-cni and sriovdp deprovision support HOT 4
- Create CDI deployment task fails HOT 4
- CI failing on rbac test for view being able to use subresource HOT 4
- "Version" on CDI main.yaml HOT 7
- hardcoded kubevirt namespace HOT 4
- virt-operator pod failed to start due to the error 'netplugin failed but error parsing its diagnostic message "": unexpected end of JSON input' HOT 12
- Support for Openshift 4 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kubevirt-ansible.