Giter VIP home page Giter VIP logo

Comments (15)

gbenhaim avatar gbenhaim commented on August 31, 2024

Hi @jcpowermac,
I totally agree that the project needs reorganization.
From my POV this project has 2 main purposes:

  1. 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 of kubevirt.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.

  2. 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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

@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.

eedri avatar eedri commented on August 31, 2024

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.

eedri avatar eedri commented on August 31, 2024

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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

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.

rthallisey avatar rthallisey commented on August 31, 2024

@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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

@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.

rthallisey avatar rthallisey commented on August 31, 2024
    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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

@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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

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.

rthallisey avatar rthallisey commented on August 31, 2024

@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.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

@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.

rthallisey avatar rthallisey commented on August 31, 2024

@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.

gbenhaim avatar gbenhaim commented on August 31, 2024

#84
#90
#91
#92
#93

from kubevirt-ansible.

lukas-bednar avatar lukas-bednar commented on August 31, 2024

@gbenhaim @rthallisey I think we can close this one as done, unless you have objection.

from kubevirt-ansible.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.