[sdk][tc] A new home for Gophercloud
Hi everyone,
The Gophercloud project is a stable OpenStack SDK in Golang, which has been widely used by many communities now, including Terraform and all the Kubernetes on OpenStack projects.
The project was initiated by Rackspace in 2013 and has already successfully managed their departure as a principal contributor. Fast forward to 2021, Joe Topjian (major maintainer) who used to be an active contributor in Puppet modules and also a voice in the OpenStack operators space, has reached out to me so we can discuss a transition for maintenance: https://github.com/gophercloud/gophercloud/issues/2246
We have discussed this internally and here are our notes: https://github.com/gophercloud/gophercloud/issues/2246#issuecomment-95758940... .
To make it short, we are figuring out whether it would make sense to find a new home for the project and if yes, where.
The main reason we're reaching out to the opendev community first is because we think this is the most logical place to host the project, alongside OpenStack:
Some ideas:
-
The project would potentially have more visibility in the community, it’s a SDK therefore strongly relying on OpenStack APIs stability. -
Use (some) opendev tools, mainly Zuul & nodepool resources - integrate with other projects. -
Governance: -
Gerrit / not Gerrit: we don’t think we would move to Gerrit yet, as the existing contributors are probably more used to the Github workflow, and we clearly don’t want to lose anyone in the process). -
IRC: we could have an IRC channel, potentially Slack as well.
Many things to figure out and before we answer these questions, we would like to poll the community: what do you think? Have you contributed to the project? What's your feeling about the ideas here?
We welcome any feedback and will take it in consideration in our discussions.
Thanks everyone,
Hey,
With openstacksdk maintainer hat and without any hat I would clearly welcome this move.
Regards, Artem
On 3. Nov 2021, at 17:13, Emilien Macchi emilien@redhat.com wrote:
Hi everyone,
The Gophercloud project is a stable OpenStack SDK in Golang, which has been widely used by many communities now, including Terraform and all the Kubernetes on OpenStack projects. The project was initiated by Rackspace in 2013 and has already successfully managed their departure as a principal contributor. Fast forward to 2021, Joe Topjian (major maintainer) who used to be an active contributor in Puppet modules and also a voice in the OpenStack operators space, has reached out to me so we can discuss a transition for maintenance: https://github.com/gophercloud/gophercloud/issues/2246 https://github.com/gophercloud/gophercloud/issues/2246 We have discussed this internally and here are our notes: https://github.com/gophercloud/gophercloud/issues/2246#issuecomment-95758940... https://github.com/gophercloud/gophercloud/issues/2246#issuecomment-957589400.
To make it short, we are figuring out whether it would make sense to find a new home for the project and if yes, where. The main reason we're reaching out to the opendev community first is because we think this is the most logical place to host the project, alongside OpenStack:
Some ideas: The project would potentially have more visibility in the community, it’s a SDK therefore strongly relying on OpenStack APIs stability. Use (some) opendev tools, mainly Zuul & nodepool resources - integrate with other projects. Governance: Gerrit / not Gerrit: we don’t think we would move to Gerrit yet, as the existing contributors are probably more used to the Github workflow, and we clearly don’t want to lose anyone in the process). IRC: we could have an IRC channel, potentially Slack as well.
Many things to figure out and before we answer these questions, we would like to poll the community: what do you think? Have you contributed to the project? What's your feeling about the ideas here? We welcome any feedback and will take it in consideration in our discussions.
Thanks everyone,
Emilien Macchi, on behalf of the Gophercloud contributors
On 2021-11-03 12:13:03 -0400 (-0400), Emilien Macchi wrote: [...]
To make it short, we are figuring out whether it would make sense to find a new home for the project and if yes, where.
The main reason we're reaching out to the opendev community first is because we think this is the most logical place to host the project, alongside OpenStack:
[...]
Use (some) opendev tools, mainly Zuul & nodepool resources - integrate with other projects.
Governance:
Gerrit / not Gerrit: we don’t think we would move to Gerrit yet, as the existing contributors are probably more used to the Github workflow, and we clearly don’t want to lose anyone in the process).
[...]
Hosting the project in the OpenDev Collaboratory would mean having its source code in our review.opendev.org Gerrit service as the primary reference copy and updating it through change proposals using a Gerrit workflow. You could replicate code to GitHub as is done for OpenStack's repositories, but the code copy on GitHub would merely serve as a read-only mirror.
While the Zuul software does have a GitHub driver and OpenDev connects their zuul.opendev.org deployment to GitHub in order to provide advisory testing to dependencies of projects hosted in OpenDev, the OpenDev sysadmins concluded that gating projects hosted outside of the OpenDev Collaboratory's Gerrit instance (e.g., on GitHub) is not something we were able to support sustainably:
http://lists.openstack.org/pipermail/openstack-infra/2019-January/006269.htm...
This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org wrote: [...]
This was based on experiences trying to work with the Kata
community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack
I haven't seen much pushback from moving to Gerrit, but pretty much all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included). Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool".
Some ideas: * Consider it as a subproject from OpenStack SDK? Or part of a SIG? * CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI) * Getting more exposure of the project and potentially more contributors * Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
Is there any concern would we have to discuss?
On Tue, Nov 9, 2021 at 6:40 PM Emilien Macchi emilien@redhat.com wrote:
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org wrote: [...]
This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack
I haven't seen much pushback from moving to Gerrit, but pretty much all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included). Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool".
Some ideas:
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
My $0.01 opinion is to move the OpenStack SDK "project" to be a generic "SDK" project, in which gophercloud could live. Mainly for a point of contact perspective, but I think "whatever works" may be best in the end.
- CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI)
I strongly suspect it wouldn't be hard to convince ironic contributors to do something similar for Ironic's CI.
- Getting more exposure of the project and potentially more contributors
- Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
On a plus side, the official SDK list could be updated... This would be kind of epic, actually.
Is there any concern would we have to discuss?
Emilien Macchi
Em qua., 10 de nov. de 2021 às 02:49, Julia Kreger < juliaashleykreger@gmail.com> escreveu:
On Tue, Nov 9, 2021 at 6:40 PM Emilien Macchi emilien@redhat.com wrote:
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org
wrote:
[...]
This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack
I haven't seen much pushback from moving to Gerrit, but pretty much all
feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included).
Beside that, if we would move to opendev, I want to see some incentives
in our roadmap, not just "move our project here because it's cool".
Some ideas:
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
My $0.01 opinion is to move the OpenStack SDK "project" to be a generic "SDK" project, in which gophercloud could live. Mainly for a point of contact perspective, but I think "whatever works" may be best in the end.
I agree with Julia's comment here.
- CI coverage for API regression testing (e.g.
gophercloud/acceptance/compute running in Nova CI)
I strongly suspect it wouldn't be hard to convince ironic contributors to do something similar for Ironic's CI.
++ I will be more than happy to help with this since I've contributed to gophercloud, and I've also helped them to add a job that runs Ironic so we could run acceptance tests.
- Getting more exposure of the project and potentially more contributors
- Consolidate the best practices in general, for contributions to the
project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
On a plus side, the official SDK list could be updated... This would be kind of epic, actually.
++ I think this would be very good.
Is there any concern would we have to discuss?
Emilien Macchi
On Tue, 2021-11-09 at 20:36 -0500, Emilien Macchi wrote:
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org wrote: [...]
This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack
I haven't seen much pushback from moving to Gerrit, but pretty much all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included). Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool".
Some ideas:
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
- CI coverage for API regression testing (e.g.
gophercloud/acceptance/compute running in Nova CI)
- Getting more exposure of the project and potentially more
contributors
- Consolidate the best practices in general, for contributions to the
project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
Is there any concern would we have to discuss?
Besides that with DevStack and its stable branches you have an easy way to test Gophercloud against various OpenStack versions.
---- On Tue, 09 Nov 2021 19:36:00 -0600 Emilien Macchi emilien@redhat.com wrote ----
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org wrote: [...] This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack I haven't seen much pushback from moving to Gerrit, but pretty much all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included).Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool". Some ideas:* Consider it as a subproject from OpenStack SDK? Or part of a SIG?* CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI)* Getting more exposure of the project and potentially more contributors* Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs). Is there any concern would we have to discuss?--
+1, Thanks Emilien for putting the roadmap which is more clear to understand the logn term benefits.
Looks good to me, especially CI part is cool to have from API testing perspective and to know where we break things (we run client jobs in many projects CI so it should not be something special we need to do)
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
Just to be more clear on this. Does this mean, once we setup the things in opendev then we can migrate it under openstack/ namespace under OpenStack SDK umbrella? or you mean keep it in opendev with non-openstack namespace but collaborative effort with SDK team.
-gmann
Emilien Macchi
On Wed, Nov 10, 2021 at 2:06 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Tue, 09 Nov 2021 19:36:00 -0600 Emilien Macchi < emilien@redhat.com> wrote ----
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org
wrote:
[...] This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack I haven't seen much pushback from moving to Gerrit, but pretty much all
feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included).Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool".
Some ideas:* Consider it as a subproject from OpenStack SDK? Or part of
a SIG?* CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI)* Getting more exposure of the project and potentially more contributors* Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
Is there any concern would we have to discuss?--
+1, Thanks Emilien for putting the roadmap which is more clear to understand the logn term benefits.
Looks good to me, especially CI part is cool to have from API testing perspective and to know where we break things (we run client jobs in many projects CI so it should not be something special we need to do)
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
Just to be more clear on this. Does this mean, once we setup the things in opendev then we can migrate it under openstack/ namespace under OpenStack SDK umbrella? or you mean keep it in opendev with non-openstack namespace but collaborative effort with SDK team.
I think we would move the project under opendev with a non openstack namespace, and of course collaborate with everyone.
---- On Mon, 15 Nov 2021 09:39:56 -0600 Emilien Macchi emilien@redhat.com wrote ----
On Wed, Nov 10, 2021 at 2:06 PM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Tue, 09 Nov 2021 19:36:00 -0600 Emilien Macchi emilien@redhat.com wrote ----
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org wrote: [...] This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack I haven't seen much pushback from moving to Gerrit, but pretty much all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included).Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool". Some ideas:* Consider it as a subproject from OpenStack SDK? Or part of a SIG?* CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI)* Getting more exposure of the project and potentially more contributors* Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs). Is there any concern would we have to discuss?--
+1, Thanks Emilien for putting the roadmap which is more clear to understand the logn term benefits.
Looks good to me, especially CI part is cool to have from API testing perspective and to know where we break things (we run client jobs in many projects CI so it should not be something special we need to do)
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
Just to be more clear on this. Does this mean, once we setup the things in opendev then we can migrate it under openstack/ namespace under OpenStack SDK umbrella? or you mean keep it in opendev with non-openstack namespace but collaborative effort with SDK team.
I think we would move the project under opendev with a non openstack namespace, and of course collaborate with everyone.
Thanks for the clarification. +1, sounds like a good plan.
-gmann
-- Emilien Macchi
Is there a reason why you don't want it to be under the openstack namespace?
-Kendall
On Mon, Nov 15, 2021 at 7:40 AM Emilien Macchi emilien@redhat.com wrote:
On Wed, Nov 10, 2021 at 2:06 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Tue, 09 Nov 2021 19:36:00 -0600 Emilien Macchi < emilien@redhat.com> wrote ----
On Wed, Nov 3, 2021 at 12:43 PM Jeremy Stanley fungi@yuggoth.org
wrote:
[...] This was based on experiences trying to work with the Kata community, and the "experiment" referenced in that mailing list post eventually concluded with the removal of remaining Kata project configuration when https://review.opendev.org/744687 merged approximately 15 months ago.
ack I haven't seen much pushback from moving to Gerrit, but pretty much
all feedback I got was from folks who worked (is working) on OpenStack, so a bit biased in my opinion (myself included).Beside that, if we would move to opendev, I want to see some incentives in our roadmap, not just "move our project here because it's cool".
Some ideas:* Consider it as a subproject from OpenStack SDK? Or part
of a SIG?* CI coverage for API regression testing (e.g. gophercloud/acceptance/compute running in Nova CI)* Getting more exposure of the project and potentially more contributors* Consolidate the best practices in general, for contributions to the project, getting started, dev environments, improving CI jobs (current jobs use OpenLab zuul, with a fork of zuul jobs).
Is there any concern would we have to discuss?--
+1, Thanks Emilien for putting the roadmap which is more clear to understand the logn term benefits.
Looks good to me, especially CI part is cool to have from API testing perspective and to know where we break things (we run client jobs in many projects CI so it should not be something special we need to do)
- Consider it as a subproject from OpenStack SDK? Or part of a SIG?
Just to be more clear on this. Does this mean, once we setup the things in opendev then we can migrate it under openstack/ namespace under OpenStack SDK umbrella? or you mean keep it in opendev with non-openstack namespace but collaborative effort with SDK team.
I think we would move the project under opendev with a non openstack namespace, and of course collaborate with everyone.
-- Emilien Macchi
Hey Kendall,
On Mon, Nov 15, 2021 at 11:59 AM Kendall Nelson kennelson11@gmail.com wrote:
Is there a reason why you don't want it to be under the openstack namespace?
The only reason that comes to my mind is not technical at all. I (not saying we, since we haven't reached consensus yet) think that we want the project in its own organization, rather than under openstack. We want to encourage external contributions from outside of OpenStack, therefore opendev would probably suit better than openstack.
This is open for discussion of course, but as I see it going, these are my personal thoughts.
Thanks,
Fair enough. Was just curious if there was some technical reason.
I think it would make more sense for the SDKs to live together, personally, but I can also see how having it live inside OpenStack can be daunting for a new, external contributor.
-Kendall
On Mon, Nov 15, 2021 at 4:32 PM Emilien Macchi emilien@redhat.com wrote:
Hey Kendall,
On Mon, Nov 15, 2021 at 11:59 AM Kendall Nelson kennelson11@gmail.com wrote:
Is there a reason why you don't want it to be under the openstack namespace?
The only reason that comes to my mind is not technical at all. I (not saying we, since we haven't reached consensus yet) think that we want the project in its own organization, rather than under openstack. We want to encourage external contributions from outside of OpenStack, therefore opendev would probably suit better than openstack.
This is open for discussion of course, but as I see it going, these are my personal thoughts.
Thanks,
Emilien Macchi
On Fri, Nov 19, 2021 at 1:11 PM Kendall Nelson kennelson11@gmail.com wrote:
Fair enough. Was just curious if there was some technical reason.
I think it would make more sense for the SDKs to live together, personally, but I can also see how having it live inside OpenStack can be daunting for a new, external contributor.
If it was me only, Gophercloud would move to opendev right now, I can only think about its benefits by my experience with the community and our amazing tools / workflows. But because I'm biased and the decision is not up to me only, I'm trying to see if this decision would be well welcomed. So far the feedback from non-OpenStack contributors was (in a nutshell, and roughly summarized): "We like the Github ecosystem, don't know much about Gerrit but if this gets too complicated I'll give up my PRs. However I agree we need to make CI better".
So this is where we are... In an ideal world we would keep Github for issues & PRs, and use Opendev Infra, but I understand this isn't possible. For now, we're doing nothing except trying to stabilize our CI until we finally make a decision whether we move or not.
I hope this email explains well enough why we haven't made any move yet.
Emilien
-Kendall
On Mon, Nov 15, 2021 at 4:32 PM Emilien Macchi emilien@redhat.com wrote:
Hey Kendall,
On Mon, Nov 15, 2021 at 11:59 AM Kendall Nelson kennelson11@gmail.com wrote:
Is there a reason why you don't want it to be under the openstack namespace?
The only reason that comes to my mind is not technical at all. I (not saying we, since we haven't reached consensus yet) think that we want the project in its own organization, rather than under openstack. We want to encourage external contributions from outside of OpenStack, therefore opendev would probably suit better than openstack.
This is open for discussion of course, but as I see it going, these are my personal thoughts.
Thanks,
Emilien Macchi
participants (8)
-
Artem Goncharov
-
Emilien Macchi
-
Ghanshyam Mann
-
Iury Gregory
-
Jeremy Stanley
-
Julia Kreger
-
Kendall Nelson
-
Michał Dulko