search

ansible-collections / community.kubevirt

KubeVirt Collection of Ansible.
http://galaxy.ansible.com/community/kubevirt
GNU General Public License v3.0
8 stars 13 forks source link

Get working with k8s.core 2 and above #34

Closed snecklifter closed 1 year ago

snecklifter commented 3 years ago
SUMMARY

Fixes #33

ISSUE TYPE
codecov[bot] commented 3 years ago

Codecov Report

Merging #34 (0c28bea) into main (3414a94) will decrease coverage by 24.84%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##             main      #34       +/-   ##
===========================================
- Coverage   62.31%   37.47%   -24.85%     
===========================================
  Files          11        5        -6     
  Lines         820      499      -321     
  Branches      146       85       -61     
===========================================
- Hits          511      187      -324     
- Misses        253      299       +46     
+ Partials       56       13       -43
Impacted Files Coverage Δ
...irt/tests/unit/plugins/modules/test_kubevirt_vm.py 7.14% <0.00%> (-92.86%) :arrow_down:
...irt/tests/unit/plugins/modules/test_kubevirt_rs.py 9.52% <0.00%> (-90.48%) :arrow_down:
...ommunity/kubevirt/plugins/module_utils/kubevirt.py 27.69% <0.00%> (-25.69%) :arrow_down:
...t/tests/unit/plugins/module_utils/test_kubevirt.py 100.00% <0.00%> (ø)
...tions/community/kubevirt/tests/unit/compat/mock.py
.../community/kubevirt/plugins/modules/kubevirt_rs.py
...unity/kubevirt/tests/unit/plugins/modules/utils.py
.../community/kubevirt/plugins/modules/kubevirt_vm.py
...s/community/kubevirt/tests/unit/compat/unittest.py
...rt/tests/unit/plugins/modules/kubevirt_fixtures.py
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 3414a94...0c28bea. Read the comment docs.

snecklifter commented 3 years ago

@Andersson007 @mnecas this is what I've managed so far. The unit tests for 2.9 are failing and some are being skipped for the rest. Would appreciate some eyes as this is obviously a large breaking change and working with python isn't my day job. But its a start... :)

Andersson007 commented 3 years ago

@snecklifter thanks for the PR! I see units against 2.9 failed

Andersson007 commented 3 years ago

also this definitely requires manual testing

Andersson007 commented 3 years ago

Several important things:

  1. When the PR is ready for merge, i would announce the changes in a separate dedicated PR (let's call it the announcement PR) that will add only a similar changelog fragment announcing the breaking changes that will be introduced in 2.0.0, etc.
  2. We should merge the announcement PR ASAP and release the fragment with the next minor / patch release.
  3. We should have a porting guide as well.
  4. IMO, we should plan 2.0.0 release right after Ansible 5.0.0 (IIRC in November) because a) users should be informed some time before, have porting guide ready, etc. b) If we release 2.0.0 after Ansible 5.0.0, 2.0.0 will be included in Ansible 6.0.0 but will be available for manual installation from Galaxy. It will allow to mitigate the move and avoid mass production failings and anger (as well as stress for us).
  5. We should merge this PR right before 2.0.0 release.
  6. Would be a great thing releasing an alpha version first and waiting for feedback from users (we can announce this in Bullhorn, IRC, etc.). See community.dns release history as an example. It will prevent inclusion of the release in Ansible and accident installations via ansilbe-galaxy --latest but will allow interested users to install and test the version through specifying that alpha version directly.
snecklifter commented 3 years ago

Several important things:

  1. When the PR is ready for merge, i would announce the changes in a separate dedicated PR (let's call it the announcement PR) that will add only a similar changelog fragment announcing the breaking changes that will be introduced in 2.0.0, etc.
  2. We should merge the announcement PR ASAP and release the fragment with the next minor / patch release.
  3. We should have a porting guide as well.
  4. IMO, we should plan 2.0.0 release right after Ansible 5.0.0 (IIRC in November) because a) users should be informed some time before, have porting guide ready, etc. b) If we release 2.0.0 after Ansible 5.0.0, 2.0.0 will be included in Ansible 6.0.0 but will be available for manual installation from Galaxy. It will allow to mitigate the move and avoid mass production failings and anger (as well as stress for us).
  5. We should merge this PR right before 2.0.0 release.
  6. Would be a great thing releasing an alpha version first and waiting for feedback from users (we can announce this in Bullhorn, IRC, etc.). See community.dns release history as an example. It will prevent inclusion of the release in Ansible and accident installations via ansilbe-galaxy --latest but will allow interested users to install and test the version through specifying that alpha version directly.

This all makes sense to me, would just appreciate some input on the failing tests if anyone has the bandwidth.

Andersson007 commented 3 years ago

This all makes sense to me, would just appreciate some input on the failing tests if anyone has the bandwidth.

OK, i'll try to take a look on Monday

jseguillon commented 2 years ago

Hi everyone, As explained in #27 I'm especially concerned in keeping this collection alive since its a dependency for molecule KubeVirt driver I'm maintaining (https://github.com/jseguillon/molecule-kubevirt).

@snecklifter are you still motivated in working on this issue ? @tadeboro same question for review ?

tadeboro commented 2 years ago

@tadeboro same question for review?

I more or less stopped using Ansible and following the things happening in the community, so it would be better to find a reviewer with more up-to-date Ansible and community knowledge.