6:53 a.m.
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the details
below.
1. The current master branch will be renamed to legacy. The usage of
this provider will be phased out within Red Hat around the end / beginning
of next year. If you want to create a fork, we are happy to add a link to
your fork to the readme.
2. A new main branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>;. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>) This
provider will only have limited functionality in its first release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will be
released as version v2.0.0 when ready to signal that it is built on the
Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the v1 branch
and backported to the Terraform SDK v1 for the benefit of the OpenShift
Installer <https://github.com/openshift/installer>;. We will not tag any
releases, and we will not release this backported version in binary form.
5. We are hosting a *community call* on the 14th of October at 13:00 UTC
on this link <https://bluejeans.com/476587312/8047>;. Please join to
provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at EMSL-MSC
<http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The oVirt fork of
this provider is about 2 years old and went through rapid expansion, adding
a large number of features.
Unfortunately, this continuous rapid growth came at a price: the original
test infrastructure deteriorated and certain resources, especially the
virtual machine creation ballooned to a size we feel has become
unmaintainable.
If you tried to contribute to the Terraform provider recently, you may have
noticed that our review process has become extremely slow. We can no longer
run the original tests, and our end to end test suite is not integrated
outside of the OpenShift CI system. Every change to the provider requires
one of only 3 people to review the code and also run a manual test suite
that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and then
subsequently slowly transition API calls to go-ovirt-client, but that
resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and cannot in
good conscience be merged in a single piece. Splitting it up is difficult,
and would likely result in broken functionality where test coverage is not
present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
You will notice that the provider currently only supports a small set of
features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
we are planning for the first release on GitHub. However, if you are using
resources like cluster creation, etc. these will currently not work and we
recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs to
create, we will create resources that are only calling one API. This will
lead to fewer bugs. For example:
- ovirt_vm will create the VM, but not attach any disks or network
interfaces to it.
- ovirt_disk_attachment or ovirt_disk_attachments will attach a disk to
the VM.
- ovirt_nic will create a network interface.
- ovirt_vm_start will start the virtual machine when provisioned, stop
it when deprovisioned.
You can use the depends_on
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached before
you start the VM. Alternatively, you can hot-plug network interfaces later.
For example:
resource "ovirt_vm" "test" {
cluster_id = "some-cluster-id"
template_id = "some-template-id"
}
resource "ovirt_disk" "test" {
storagedomain_id = "some-storage-domain-id"
format = "cow"
size = 512
alias = "test"
sparse = true
}
resource "ovirt_disk_attachment" "test" {
vm_id = ovirt_vm.test.id
disk_id = ovirt_disk.test.id
disk_interface = "virtio_scsi"
}
resource "ovirt_vm_start" "test" {
vm_id = ovirt_vm.test.id
depends_on = [ovirt_disk_attachment.test]
}
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you will
be able to simply pull in the provider like this:
terraform {
required_providers {
ovirt = {
source = "ovirt/ovirt"
version = "..."
}
}
}
provider "ovirt" {
# Configuration options
}
The configuration options for the provider itself have also been greatly
expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library. The
single biggest advantage of this library is that it has built-in mocks for
all resources it supports. Having mocks allows us to run tests without
needing to spin up an oVirt instance. We have already configured GitHub
Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions> on
the new provider and all changes are automatically checked against these
mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider, since
this is the primary motivation for the change. The OpenShift Installer uses
the legacy version 1 of the Terraform SDK, so we will maintain a version
1-compatible copy in the v1 branch, which the installer can pull in. It is
important to note, however, that the v1 branch will be a pure backport, we
will not develop it separately. Development will be focused on the version
in main that is being released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>;. Unfortunately,
we currently do not have the capacity to properly vet and and run our
internal test suite against these changes. In contrast to the new Terraform
provider, we do not have working tests, linting, and the code structure
that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be merged*. We
know that this is a terrible thing, you have put in effort into writing
them. Unfortunately, we do not see an alternative as there already numerous
bugs on our radar and adding more code would not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been keeping up
with reviewing your contributions and issues. Some are several months old
and haven’t received answers for a long time. We want to change that, we
want to hear from you. Please join our community round table around the
Terraform provider on the 14th of October at 13:00 UTC on this link
<https://bluejeans.com/476587312/8047>;.
*We want to know: Which resources are the most important to you? How does
this change impact you? Can we make the transition smoother for you? Would
you do anything differently in the light of the issues described above?*
11:48 a.m.
hi,
*
*
*Which resources are the most important to you?
*
VM, nic*
*
*How does this change impact you?
*
rewrite current code
**
*Can we make the transition smoother for you?
*
some transition guide/tips
**
*Would you do anything differently in the light of the issues described
above?*
no
p.s. thank you for terraform provider and publishing it to the terraform
registry!
p.s.2 any chance that 2.0 solve this problem ?
https://github.com/oVirt/terraform-provider-ovirt/issues/217 ;)
Marek
Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the
details below.
1. The current |master| branch will be renamed to |legacy|. The usage
of this provider will be phased out within Red Hat around the end
/ beginning of next year. If you want to create a fork, we are
happy to add a link to your fork to the readme.
2. A new |main| branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>;. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>)
This provider will only have limited functionality in its first
release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will
be released as version v2.0.0 when ready to signal that it is
built on the Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the |v1|
branch and backported to the Terraform SDK v1 for the benefit of
the OpenShift Installer <https://github.com/openshift/installer>;.
We will not tag any releases, and we will not release this
backported version in binary form.
5. We are hosting a *community call* on the 14th of October at 13:00
UTC on this link <https://bluejeans.com/476587312/8047>;. Please
join to provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at
EMSL-MSC <http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The
oVirt fork of this provider is about 2 years old and went through
rapid expansion, adding a large number of features.
Unfortunately, this continuous rapid growth came at a price: the
original test infrastructure deteriorated and certain resources,
especially the virtual machine creation ballooned to a size we feel
has become unmaintainable.
If you tried to contribute to the Terraform provider recently, you may
have noticed that our review process has become extremely slow. We can
no longer run the original tests, and our end to end test suite is not
integrated outside of the OpenShift CI system. Every change to the
provider requires one of only 3 people to review the code and also run
a manual test suite that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and
then subsequently slowly transition API calls to go-ovirt-client, but
that resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and
cannot in good conscience be merged in a single piece. Splitting it up
is difficult, and would likely result in broken functionality where
test coverage is not present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation
here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
You will notice that the provider currently only supports a small set
of features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
we are planning for the first release on GitHub. However, if you are
using resources like cluster creation, etc. these will currently not
work and we recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs
to create, we will create resources that are only calling one API.
This will lead to fewer bugs. For example:
* |ovirt_vm| will create the VM, but not attach any disks or network
interfaces to it.
* |ovirt_disk_attachment| or |ovirt_disk_attachments| will attach a
disk to the VM.
* |ovirt_nic| will create a network interface.
* |ovirt_vm_start| will start the virtual machine when provisioned,
stop it when deprovisioned.
You can use the |depends_on|
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached
before you start the VM. Alternatively, you can hot-plug network
interfaces later. For example:
|resource "ovirt_vm" "test" { cluster_id =
"some-cluster-id"
template_id = "some-template-id" } resource "ovirt_disk"
"test" {
storagedomain_id = "some-storage-domain-id" format = "cow" size = 512
alias = "test" sparse = true } resource "ovirt_disk_attachment"
"test"
{ vm_id = ovirt_vm.test.id <http://ovirt_vm.test.id> disk_id =
ovirt_disk.test.id <http://ovirt_disk.test.id> disk_interface =
"virtio_scsi" } resource "ovirt_vm_start" "test" { vm_id =
ovirt_vm.test.id <http://ovirt_vm.test.id> depends_on =
[ovirt_disk_attachment.test] }|
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you
will be able to simply pull in the provider like this:
|terraform { required_providers { ovirt = { source = "ovirt/ovirt"
version = "..." } } } provider "ovirt" { # Configuration options }|
The configuration options for the provider itself have also been
greatly expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library.
The single biggest advantage of this library is that it has built-in
mocks for all resources it supports. Having mocks allows us to run
tests without needing to spin up an oVirt instance. We have already
configured GitHub Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions>
on the new provider and all changes are automatically checked against
these mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider,
since this is the primary motivation for the change. The OpenShift
Installer uses the legacy version 1 of the Terraform SDK, so we will
maintain a version 1-compatible copy in the |v1| branch, which the
installer can pull in. It is important to note, however, that the |v1|
branch will be a pure backport, we will not develop it separately.
Development will be focused on the version in |main| that is being
released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>;.
Unfortunately, we currently do not have the capacity to properly vet
and and run our internal test suite against these changes. In contrast
to the new Terraform provider, we do not have working tests, linting,
and the code structure that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be
merged*. We know that this is a terrible thing, you have put in effort
into writing them. Unfortunately, we do not see an alternative as
there already numerous bugs on our radar and adding more code would
not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been
keeping up with reviewing your contributions and issues. Some are
several months old and haven’t received answers for a long time. We
want to change that, we want to hear from you. Please join our
community round table around the Terraform provider on the 14th of
October at 13:00 UTC on this link <https://bluejeans.com/476587312/8047>;.
*We want to know: Which resources are the most important to you? How
does this change impact you? Can we make the transition smoother for
you? Would you do anything differently in the light of the issues
described above?*
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWMC6MORNBQ...
1:23 a.m.
Hello Marek,
Thank you for your feedback, VM and NIC management will be covered. I will
add your issue as a test case and I will notify you on the issue when you
can give it a go.
Your point about transition documentation is also noted, I will add a guide
outlining the changes you need to make to your code. (This will actually
come in handy for us internally too, so double thanks for the suggestion!)
Janos
On Wed, Oct 6, 2021, 5:52 PM marek <cervajs64(a)gmail.com> wrote:
hi,
*Which resources are the most important to you? *
VM, nic
*How does this change impact you? *
rewrite current code
*Can we make the transition smoother for you? *
some transition guide/tips
*Would you do anything differently in the light of the issues described
above?*
no
p.s. thank you for terraform provider and publishing it to the terraform
registry!
p.s.2 any chance that 2.0 solve this problem ?
https://github.com/oVirt/terraform-provider-ovirt/issues/217 ;)
Marek
Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the
details below.
1. The current master branch will be renamed to legacy. The usage of
this provider will be phased out within Red Hat around the end / beginning
of next year. If you want to create a fork, we are happy to add a link to
your fork to the readme.
2. A new main branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>;. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>) This
provider will only have limited functionality in its first release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will be
released as version v2.0.0 when ready to signal that it is built on the
Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the v1 branch
and backported to the Terraform SDK v1 for the benefit of the OpenShift
Installer <https://github.com/openshift/installer>;. We will not tag
any releases, and we will not release this backported version in binary
form.
5. We are hosting a *community call* on the 14th of October at 13:00
UTC on this link <https://bluejeans.com/476587312/8047>;. Please join
to provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at
EMSL-MSC <http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The oVirt
fork of this provider is about 2 years old and went through rapid
expansion, adding a large number of features.
Unfortunately, this continuous rapid growth came at a price: the original
test infrastructure deteriorated and certain resources, especially the
virtual machine creation ballooned to a size we feel has become
unmaintainable.
If you tried to contribute to the Terraform provider recently, you may
have noticed that our review process has become extremely slow. We can no
longer run the original tests, and our end to end test suite is not
integrated outside of the OpenShift CI system. Every change to the provider
requires one of only 3 people to review the code and also run a manual test
suite that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and then
subsequently slowly transition API calls to go-ovirt-client, but that
resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and cannot
in good conscience be merged in a single piece. Splitting it up is
difficult, and would likely result in broken functionality where test
coverage is not present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation
here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
You will notice that the provider currently only supports a small set of
features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
we are planning for the first release on GitHub. However, if you are using
resources like cluster creation, etc. these will currently not work and we
recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs to
create, we will create resources that are only calling one API. This will
lead to fewer bugs. For example:
- ovirt_vm will create the VM, but not attach any disks or network
interfaces to it.
- ovirt_disk_attachment or ovirt_disk_attachments will attach a disk
to the VM.
- ovirt_nic will create a network interface.
- ovirt_vm_start will start the virtual machine when provisioned, stop
it when deprovisioned.
You can use the depends_on
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached before
you start the VM. Alternatively, you can hot-plug network interfaces later.
For example:
resource "ovirt_vm" "test" {
cluster_id = "some-cluster-id"
template_id = "some-template-id"
}
resource "ovirt_disk" "test" {
storagedomain_id = "some-storage-domain-id"
format = "cow"
size = 512
alias = "test"
sparse = true
}
resource "ovirt_disk_attachment" "test" {
vm_id = ovirt_vm.test.id
disk_id = ovirt_disk.test.id
disk_interface = "virtio_scsi"
}
resource "ovirt_vm_start" "test" {
vm_id = ovirt_vm.test.id
depends_on = [ovirt_disk_attachment.test]
}
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you will
be able to simply pull in the provider like this:
terraform {
required_providers {
ovirt = {
source = "ovirt/ovirt"
version = "..."
}
}
}
provider "ovirt" {
# Configuration options
}
The configuration options for the provider itself have also been greatly
expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library. The
single biggest advantage of this library is that it has built-in mocks for
all resources it supports. Having mocks allows us to run tests without
needing to spin up an oVirt instance. We have already configured GitHub
Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions>
on the new provider and all changes are automatically checked against these
mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider, since
this is the primary motivation for the change. The OpenShift Installer uses
the legacy version 1 of the Terraform SDK, so we will maintain a version
1-compatible copy in the v1 branch, which the installer can pull in. It
is important to note, however, that the v1 branch will be a pure
backport, we will not develop it separately. Development will be focused on
the version in main that is being released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>;. Unfortunately,
we currently do not have the capacity to properly vet and and run our
internal test suite against these changes. In contrast to the new Terraform
provider, we do not have working tests, linting, and the code structure
that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be merged*.
We know that this is a terrible thing, you have put in effort into writing
them. Unfortunately, we do not see an alternative as there already numerous
bugs on our radar and adding more code would not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been keeping
up with reviewing your contributions and issues. Some are several months
old and haven’t received answers for a long time. We want to change that,
we want to hear from you. Please join our community round table around the
Terraform provider on the 14th of October at 13:00 UTC on this link
<https://bluejeans.com/476587312/8047>;.
*We want to know: Which resources are the most important to you? How does
this change impact you? Can we make the transition smoother for you? Would
you do anything differently in the light of the issues described above?*
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWMC6MORNBQ...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F64EGQXZZDA...
3:58 p.m.
Hi,
any plan for release?
Marek
Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the
details below.
1. The current |master| branch will be renamed to |legacy|. The usage
of this provider will be phased out within Red Hat around the end
/ beginning of next year. If you want to create a fork, we are
happy to add a link to your fork to the readme.
2. A new |main| branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>;. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>)
This provider will only have limited functionality in its first
release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will
be released as version v2.0.0 when ready to signal that it is
built on the Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the |v1|
branch and backported to the Terraform SDK v1 for the benefit of
the OpenShift Installer <https://github.com/openshift/installer>;.
We will not tag any releases, and we will not release this
backported version in binary form.
5. We are hosting a *community call* on the 14th of October at 13:00
UTC on this link <https://bluejeans.com/476587312/8047>;. Please
join to provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at
EMSL-MSC <http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The
oVirt fork of this provider is about 2 years old and went through
rapid expansion, adding a large number of features.
Unfortunately, this continuous rapid growth came at a price: the
original test infrastructure deteriorated and certain resources,
especially the virtual machine creation ballooned to a size we feel
has become unmaintainable.
If you tried to contribute to the Terraform provider recently, you may
have noticed that our review process has become extremely slow. We can
no longer run the original tests, and our end to end test suite is not
integrated outside of the OpenShift CI system. Every change to the
provider requires one of only 3 people to review the code and also run
a manual test suite that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and
then subsequently slowly transition API calls to go-ovirt-client, but
that resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and
cannot in good conscience be merged in a single piece. Splitting it up
is difficult, and would likely result in broken functionality where
test coverage is not present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation
here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
You will notice that the provider currently only supports a small set
of features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
we are planning for the first release on GitHub. However, if you are
using resources like cluster creation, etc. these will currently not
work and we recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs
to create, we will create resources that are only calling one API.
This will lead to fewer bugs. For example:
* |ovirt_vm| will create the VM, but not attach any disks or network
interfaces to it.
* |ovirt_disk_attachment| or |ovirt_disk_attachments| will attach a
disk to the VM.
* |ovirt_nic| will create a network interface.
* |ovirt_vm_start| will start the virtual machine when provisioned,
stop it when deprovisioned.
You can use the |depends_on|
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached
before you start the VM. Alternatively, you can hot-plug network
interfaces later. For example:
|resource "ovirt_vm" "test" { cluster_id =
"some-cluster-id"
template_id = "some-template-id" } resource "ovirt_disk"
"test" {
storagedomain_id = "some-storage-domain-id" format = "cow" size = 512
alias = "test" sparse = true } resource "ovirt_disk_attachment"
"test"
{ vm_id = ovirt_vm.test.id <http://ovirt_vm.test.id> disk_id =
ovirt_disk.test.id <http://ovirt_disk.test.id> disk_interface =
"virtio_scsi" } resource "ovirt_vm_start" "test" { vm_id =
ovirt_vm.test.id <http://ovirt_vm.test.id> depends_on =
[ovirt_disk_attachment.test] }|
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you
will be able to simply pull in the provider like this:
|terraform { required_providers { ovirt = { source = "ovirt/ovirt"
version = "..." } } } provider "ovirt" { # Configuration options }|
The configuration options for the provider itself have also been
greatly expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library.
The single biggest advantage of this library is that it has built-in
mocks for all resources it supports. Having mocks allows us to run
tests without needing to spin up an oVirt instance. We have already
configured GitHub Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions>
on the new provider and all changes are automatically checked against
these mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider,
since this is the primary motivation for the change. The OpenShift
Installer uses the legacy version 1 of the Terraform SDK, so we will
maintain a version 1-compatible copy in the |v1| branch, which the
installer can pull in. It is important to note, however, that the |v1|
branch will be a pure backport, we will not develop it separately.
Development will be focused on the version in |main| that is being
released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>;.
Unfortunately, we currently do not have the capacity to properly vet
and and run our internal test suite against these changes. In contrast
to the new Terraform provider, we do not have working tests, linting,
and the code structure that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be
merged*. We know that this is a terrible thing, you have put in effort
into writing them. Unfortunately, we do not see an alternative as
there already numerous bugs on our radar and adding more code would
not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been
keeping up with reviewing your contributions and issues. Some are
several months old and haven’t received answers for a long time. We
want to change that, we want to hear from you. Please join our
community round table around the Terraform provider on the 14th of
October at 13:00 UTC on this link <https://bluejeans.com/476587312/8047>;.
*We want to know: Which resources are the most important to you? How
does this change impact you? Can we make the transition smoother for
you? Would you do anything differently in the light of the issues
described above?*
_______________________________________________
Users mailing list --users(a)ovirt.org
To unsubscribe send an email tousers-leave(a)ovirt.org
Privacy Statement:https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/
List
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/OW...
1 p.m.
Hello Marek, hello everyone,
I'm sorry I didn't update you earlier. Unfortunately, we had a key team
member leave our team, which pushed back our release by some time. We are
still pursuing the matter according to the original plan and will release
the TF provider, but we will need some more time to work on it.
We'll keep the repository on GitHub updated with the developments we do.
Once again, I'm sorry for the delay.
Janos
On Wed, Jan 5, 2022, 10:03 PM marek <cervajs64(a)gmail.com> wrote:
Hi,
any plan for release?
Marek
Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
Dear oVirt community,
We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*
Here’s the short list what we would like to change, please read the
details below.
1. The current master branch will be renamed to legacy. The usage of
this provider will be phased out within Red Hat around the end / beginning
of next year. If you want to create a fork, we are happy to add a link to
your fork to the readme.
2. A new main branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
<https://github.com/ovirt/go-ovirt-client>;. (Preview here
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt>) This
provider will only have limited functionality in its first release.
3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will be
released as version v2.0.0 when ready to signal that it is built on the
Terraform SDK v2.
4. A copy of this new Terraform provider will be kept in the v1 branch
and backported to the Terraform SDK v1 for the benefit of the OpenShift
Installer <https://github.com/openshift/installer>;. We will not tag
any releases, and we will not release this backported version in binary
form.
5. We are hosting a *community call* on the 14th of October at 13:00
UTC on this link <https://bluejeans.com/476587312/8047>;. Please join
to provide feedback and suggest changes to this plan.
Why are we doing this?
The original Terraform provider
<https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt was
written four years ago by @Maigard <https://github.com/Maigard> at
EMSL-MSC <http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The oVirt
fork of this provider is about 2 years old and went through rapid
expansion, adding a large number of features.
Unfortunately, this continuous rapid growth came at a price: the original
test infrastructure deteriorated and certain resources, especially the
virtual machine creation ballooned to a size we feel has become
unmaintainable.
If you tried to contribute to the Terraform provider recently, you may
have noticed that our review process has become extremely slow. We can no
longer run the original tests, and our end to end test suite is not
integrated outside of the OpenShift CI system. Every change to the provider
requires one of only 3 people to review the code and also run a manual test
suite that is currently only runable on one computer.
We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.
Our original plan was that we would fix the test infrastructure and then
subsequently slowly transition API calls to go-ovirt-client, but that
resulted in a PR that is over 5000 lines in code
<https://github.com/oVirt/terraform-provider-ovirt/pull/277> and cannot
in good conscience be merged in a single piece. Splitting it up is
difficult, and would likely result in broken functionality where test
coverage is not present.
What are we changing for you, the users?
First of all, documentation. You can already preview the documentation
here
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
You will notice that the provider currently only supports a small set of
features. You can find the full list of features
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
we are planning for the first release on GitHub. However, if you are using
resources like cluster creation, etc. these will currently not work and we
recommend sticking to the old provider for the time being.
The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs to
create, we will create resources that are only calling one API. This will
lead to fewer bugs. For example:
- ovirt_vm will create the VM, but not attach any disks or network
interfaces to it.
- ovirt_disk_attachment or ovirt_disk_attachments will attach a disk
to the VM.
- ovirt_nic will create a network interface.
- ovirt_vm_start will start the virtual machine when provisioned, stop
it when deprovisioned.
You can use the depends_on
<https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
meta-argument to make sure disks and network interfaces are attached before
you start the VM. Alternatively, you can hot-plug network interfaces later.
For example:
resource "ovirt_vm" "test" {
cluster_id = "some-cluster-id"
template_id = "some-template-id"
}
resource "ovirt_disk" "test" {
storagedomain_id = "some-storage-domain-id"
format = "cow"
size = 512
alias = "test"
sparse = true
}
resource "ovirt_disk_attachment" "test" {
vm_id = ovirt_vm.test.id
disk_id = ovirt_disk.test.id
disk_interface = "virtio_scsi"
}
resource "ovirt_vm_start" "test" {
vm_id = ovirt_vm.test.id
depends_on = [ovirt_disk_attachment.test]
}
The next change is the availability of the provider on the Terraform
Registry. You will no longer have to download the binary. Instead, you will
be able to simply pull in the provider like this:
terraform {
required_providers {
ovirt = {
source = "ovirt/ovirt"
version = "..."
}
}
}
provider "ovirt" {
# Configuration options
}
The configuration options for the provider itself have also been greatly
expanded, see the preliminary documentation
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
for details.
What’s changing behind the scenes?
The new Terraform provider is a complete rewrite based on the
go-ovirt-client <https://github.com/ovirt/go-ovirt-client> library. The
single biggest advantage of this library is that it has built-in mocks for
all resources it supports. Having mocks allows us to run tests without
needing to spin up an oVirt instance. We have already configured GitHub
Actions
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions>
on the new provider and all changes are automatically checked against these
mocks.
We may decide to add an end-to-end test later, but for the foreseeable
future we will trust the correctness of the mocks to test community
contributions. This means that we will be able to merge changes much
quicker.
On the OpenShift side we will also switch to using the new provider, since
this is the primary motivation for the change. The OpenShift Installer uses
the legacy version 1 of the Terraform SDK, so we will maintain a version
1-compatible copy in the v1 branch, which the installer can pull in. It
is important to note, however, that the v1 branch will be a pure
backport, we will not develop it separately. Development will be focused on
the version in main that is being released to the Terraform Registry.
What does this mean to you, the contributors?
The current Terraform provider has several pull requests open
<https://github.com/oVirt/terraform-provider-ovirt/pulls>;. Unfortunately,
we currently do not have the capacity to properly vet and and run our
internal test suite against these changes. In contrast to the new Terraform
provider, we do not have working tests, linting, and the code structure
that make merging changes easier.
We are very sorry to say that *these patches are unlikely to be merged*.
We know that this is a terrible thing, you have put in effort into writing
them. Unfortunately, we do not see an alternative as there already numerous
bugs on our radar and adding more code would not make the problem go away.
We want to hear your opinion
As the owners of the original Terraform provider we haven’t been keeping
up with reviewing your contributions and issues. Some are several months
old and haven’t received answers for a long time. We want to change that,
we want to hear from you. Please join our community round table around the
Terraform provider on the 14th of October at 13:00 UTC on this link
<https://bluejeans.com/476587312/8047>;.
*We want to know: Which resources are the most important to you? How does
this change impact you? Can we make the transition smoother for you? Would
you do anything differently in the light of the issues described above?*
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWMC6MORNBQ...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YOZGH4J6FIW...
3:33 a.m.
New subject: Important changes to the oVirt Terraform Provider
Hi Janos,
any news?
Marek
Dne 07/01/2022 v 19:00 Janos Bonic napsal(a):
Hello Marek, hello everyone,
I'm sorry I didn't update you earlier. Unfortunately, we had a key
team member leave our team, which pushed back our release by some
time. We are still pursuing the matter according to the original plan
and will release the TF provider, but we will need some more time to
work on it.
We'll keep the repository on GitHub updated with the developments we do.
Once again, I'm sorry for the delay.
Janos
On Wed, Jan 5, 2022, 10:03 PM marek <cervajs64(a)gmail.com> wrote:
Hi,
any plan for release?
Marek
Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
>
> Dear oVirt community,
>
> We are making sweeping and backwards-incompatible changes to the
> oVirt Terraform provider. *We want your feedback before we make
> these changes.*
>
> Here’s the short list what we would like to change, please read
> the details below.
>
> 1. The current |master| branch will be renamed to |legacy|. The
> usage of this provider will be phased out within Red Hat
> around the end / beginning of next year. If you want to
> create a fork, we are happy to add a link to your fork to the
> readme.
> 2. A new |main| branch will be created and a *new Terraform
> provider* written from scratch on the basis of
> go-ovirt-client <https://github.com/ovirt/go-ovirt-client>;.
> (Preview here
> <https://github.com/haveyoudebuggedit/terraform-provider-ovirt>)
> This provider will only have limited functionality in its
> first release.
> 3. This new provider will be released to the Terraform registry,
> and will have full test coverage and documentation. This
> provider will be released as version v2.0.0 when ready to
> signal that it is built on the Terraform SDK v2.
> 4. A copy of this new Terraform provider will be kept in the
> |v1| branch and backported to the Terraform SDK v1 for the
> benefit of the OpenShift Installer
> <https://github.com/openshift/installer>;. We will not tag any
> releases, and we will not release this backported version in
> binary form.
> 5. We are hosting a *community call* on the 14th of October at
> 13:00 UTC on this link
> <https://bluejeans.com/476587312/8047>;. Please join to
> provide feedback and suggest changes to this plan.
>
>
> Why are we doing this?
>
> The original Terraform provider
> <https://github.com/EMSL-MSC/terraform-provider-ovirt> for oVirt
> was written four years ago by @Maigard
> <https://github.com/Maigard> at EMSL-MSC
> <http://github.com/EMSL-MSC/terraform-provider-ovirt>;. The oVirt
> fork of this provider is about 2 years old and went through rapid
> expansion, adding a large number of features.
>
> Unfortunately, this continuous rapid growth came at a price: the
> original test infrastructure deteriorated and certain resources,
> especially the virtual machine creation ballooned to a size we
> feel has become unmaintainable.
>
> If you tried to contribute to the Terraform provider recently,
> you may have noticed that our review process has become extremely
> slow. We can no longer run the original tests, and our end to end
> test suite is not integrated outside of the OpenShift CI system.
> Every change to the provider requires one of only 3 people to
> review the code and also run a manual test suite that is
> currently only runable on one computer.
>
> We also noticed an increasing number of bugs reported on
> OpenShift on oVirt/RHV related to the Terraform provider.
>
> Our original plan was that we would fix the test infrastructure
> and then subsequently slowly transition API calls to
> go-ovirt-client, but that resulted in a PR that is over 5000
> lines in code
> <https://github.com/oVirt/terraform-provider-ovirt/pull/277> and
> cannot in good conscience be merged in a single piece. Splitting
> it up is difficult, and would likely result in broken
> functionality where test coverage is not present.
>
>
> What are we changing for you, the users?
>
> First of all, documentation. You can already preview the
> documentation here
>
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...;.
> You will notice that the provider currently only supports a small
> set of features. You can find the full list of features
>
<https://github.com/haveyoudebuggedit/terraform-provider-ovirt/milestone/1...
> we are planning for the first release on GitHub. However, if you
> are using resources like cluster creation, etc. these will
> currently not work and we recommend sticking to the old provider
> for the time being.
>
> The second big change will be how resources are treated. Instead
> of creating large resources that need to call several of the
> oVirt APIs to create, we will create resources that are only
> calling one API. This will lead to fewer bugs. For example:
>
> * |ovirt_vm| will create the VM, but not attach any disks or
> network interfaces to it.
> * |ovirt_disk_attachment| or |ovirt_disk_attachments| will
> attach a disk to the VM.
> * |ovirt_nic| will create a network interface.
> * |ovirt_vm_start| will start the virtual machine when
> provisioned, stop it when deprovisioned.
>
> You can use the |depends_on|
> <https://www.terraform.io/docs/language/meta-arguments/depends_on.html>
> meta-argument to make sure disks and network interfaces are
> attached before you start the VM. Alternatively, you can hot-plug
> network interfaces later. For example:
>
> |resource "ovirt_vm" "test" { cluster_id =
"some-cluster-id"
> template_id = "some-template-id" } resource "ovirt_disk"
"test" {
> storagedomain_id = "some-storage-domain-id" format = "cow"
size =
> 512 alias = "test" sparse = true } resource
> "ovirt_disk_attachment" "test" { vm_id = ovirt_vm.test.id
> <http://ovirt_vm.test.id> disk_id = ovirt_disk.test.id
> <http://ovirt_disk.test.id> disk_interface = "virtio_scsi" }
> resource "ovirt_vm_start" "test" { vm_id = ovirt_vm.test.id
> <http://ovirt_vm.test.id> depends_on = [ovirt_disk_attachment.test] }|
>
> The next change is the availability of the provider on the
> Terraform Registry. You will no longer have to download the
> binary. Instead, you will be able to simply pull in the provider
> like this:
>
> |terraform { required_providers { ovirt = { source =
> "ovirt/ovirt" version = "..." } } } provider
"ovirt" { #
> Configuration options }|
>
> The configuration options for the provider itself have also been
> greatly expanded, see the preliminary documentation
>
<https://registry.terraform.io/providers/haveyoudebuggedit/ovirt/latest/do...
> for details.
>
>
> What’s changing behind the scenes?
>
> The new Terraform provider is a complete rewrite based on the
> go-ovirt-client <https://github.com/ovirt/go-ovirt-client>
> library. The single biggest advantage of this library is that it
> has built-in mocks for all resources it supports. Having mocks
> allows us to run tests without needing to spin up an oVirt
> instance. We have already configured GitHub Actions
> <https://github.com/haveyoudebuggedit/terraform-provider-ovirt/actions>
> on the new provider and all changes are automatically checked
> against these mocks.
>
> We may decide to add an end-to-end test later, but for the
> foreseeable future we will trust the correctness of the mocks to
> test community contributions. This means that we will be able to
> merge changes much quicker.
>
> On the OpenShift side we will also switch to using the new
> provider, since this is the primary motivation for the change.
> The OpenShift Installer uses the legacy version 1 of the
> Terraform SDK, so we will maintain a version 1-compatible copy in
> the |v1| branch, which the installer can pull in. It is important
> to note, however, that the |v1| branch will be a pure backport,
> we will not develop it separately. Development will be focused on
> the version in |main| that is being released to the Terraform
> Registry.
>
>
> What does this mean to you, the contributors?
>
> The current Terraform provider has several pull requests open
> <https://github.com/oVirt/terraform-provider-ovirt/pulls>;.
> Unfortunately, we currently do not have the capacity to properly
> vet and and run our internal test suite against these changes. In
> contrast to the new Terraform provider, we do not have working
> tests, linting, and the code structure that make merging changes
> easier.
>
> We are very sorry to say that *these patches are unlikely to be
> merged*. We know that this is a terrible thing, you have put in
> effort into writing them. Unfortunately, we do not see an
> alternative as there already numerous bugs on our radar and
> adding more code would not make the problem go away.
>
>
> We want to hear your opinion
>
> As the owners of the original Terraform provider we haven’t been
> keeping up with reviewing your contributions and issues. Some are
> several months old and haven’t received answers for a long time.
> We want to change that, we want to hear from you. Please join our
> community round table around the Terraform provider on the 14th
> of October at 13:00 UTC on this link
> <https://bluejeans.com/476587312/8047>;.
>
> *We want to know: Which resources are the most important to you?
> How does this change impact you? Can we make the transition
> smoother for you? Would you do anything differently in the light
> of the issues described above?*
>
>
> _______________________________________________
> Users mailing list --users(a)ovirt.org
> To unsubscribe send an email tousers-leave(a)ovirt.org
> Privacy Statement:https://www.ovirt.org/privacy-policy.html
> oVirt Code of
Conduct:https://www.ovirt.org/community/about/community-guidelines/
> List
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/OW...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YOZGH4J6FIW...
797
days inactive
951
days old
5 comments
2 participants
participants (2)
-
Janos Bonic -
marek