Separate leftover providers

[Temikus]

Ok, let's get this ball rolling, here's the list of providers that I've generated from lib:
find . -maxdepth 1 -type f | sed 's/\.\//- [ ] /g'

• bare_metal_cloud.rb - @geemus - April 1, 2017
• bluebox.rb - Need to check if is available
• clodo.rb
• cloudsigma.rb
• cloudstack.rb
• dnsimple.rb - @lanej - February 11, 2017
• dnsmadeeasy.rb
• dreamhost.rb
• fogdocker.rb
• glesys.rb
• go_grid.rb - Need to check if is available
• ibm.rb
• internet_archive.rb - @icco - March 8, 2017
• joyent.rb - @effeminate-batman - March 23, 2017
• linode.rb
• ninefold.rb - @lanej - February 23, 2017
• opennebula.rb
• openvz.rb
• ovirt.rb - @orrabin - June 26, 2017
• rage4.rb
• vcloud.rb - @jrgarcia - February 10, 2017
• vcloud_director.rb - @jrgarcia - February 10, 2017
• zerigo.rb - @plribeiro3000 - February 25, 2018

14 providers left including 2 to check if are still available.

For every provider we need to make a decision:

• Separate into its' own gem
  or
• Remove/drop support for it

@plribeiro3000 / @geemus PTAL
Also - can you give an idea (very general is ok, but at least something) on how should separation should be done ideally? I'll format it so it looks straightforward.

[plribeiro3000]

Sure. I did a very basic document on it in the past. You can find it here: https://github.com/fog/fog/wiki/Create-New-Provider-from-Scratch Is that what you are looking for? Em sex, 10 de fev de 2017 02:49, Artem Yakimenko <notifications@github.com> escreveu:

…

Ok, let's get this ball rolling, here's the list of providers that I've generated from lib: find . -maxdepth 1 -type f | sed 's/\.\//- [] /g' - [] bare_metal_cloud.rb - [] bluebox.rb - [] clodo.rb - [] cloudsigma.rb - [] cloudstack.rb - [] dnsimple.rb - [] dnsmadeeasy.rb - [] dreamhost.rb - [] fogdocker.rb - [] glesys.rb - [] go_grid.rb - [] ibm.rb - [] internet_archive.rb - [] joyent.rb - [] linode.rb - [] ninefold.rb - [] opennebula.rb - [] openvz.rb - [] ovirt.rb - [] rage4.rb - [] vcloud.rb - [] vcloud_director.rb - [] version.rb - [] zerigo.rb For every provider we need to make a decision: - Separate or - Remove @plribeiro3000 <https://github.com/plribeiro3000> / @geemus <https://github.com/geemus> PTAL Also - can you give an idea (very general is ok, but at least something) on how should separation should be done ideally? I'll format it so it looks straightforward. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3942>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApEuE_j3-bvHkHz2S-BgrJDJAL9v27Pks5ra-xIgaJpZM4L9AIE> .

[lanej]

@Temikus nice work

[lanej]

Looks like fog-dnsimple just needs removal from this gem as https://github.com/fog/fog-dnsimple already exists. @weppos can you confirm?

[plribeiro3000]

Good catch @lanej !

[weppos]

Yep, I confirm @lanej. The DNSimple provider has been moved to fog-dnsimple.

[geemus]

Awesome. If you are taking on something, please edit the comment above (or add a comment here) that says which provider, who you are and what date (so we can judge staleness). That way we don't step on one another's toes. I'll update the listing above with ones I know about.

[geemus]

I also manually removed bin.rb and version.rb from the listing (just noting as the find/sed would no longer match).

[lanej]

I think ninefold can be dropped entirely.

[plribeiro3000]

ouch. Good catch @lanej.

[geemus]

Easiest, extraction, evar. Thanks!

[icco]

I'm going to take ownership of internet_archive.

[geemus]

Thanks!

[geemus]

I need to start taking one (or some) as well, just been swamped of late...

[effeminate-batman]

I will take ownership of joyent.

[mmoll]

@b0e I guess you could take over opennebula?

[icco]

Looks like they even have a repo started: https://github.com/b0e/fog-one

[orrabin]

I'd like to take over separating ovirt.
One thing to consider is that ovirt has deprecated api v3 and that is the current version that is implemented in fog.
With api v4 there is a new gem to use instead of rbovirt that is in use today.

As the api for v3 is already deprecated I'd suggest creating fog-ovirt4 for the new api, using the new gem and leaving the ovirt part that already exists for v3 in place.
Trying to use both in the same provider would create a pretty big mess with completely different apis and 2 different gems to send requests to.
If that is acceptable I can start working on creating the provider to support api v4 as fog-ovirt4.

[icco]

Why put the version in the name? Why not just fog-ovirt and implement V4 @orrabin?

[orrabin]

@icco I'll probably need to name some things ovirt4 to avoid ambiguity with the current ovirt as long as it still exists so I thought naming the plugin was appropriate but there is no real need for it.

[icco]

Since the new one will require an explicit include, I'd say just name it ovirt. Chance of collision seems low to me.

[plribeiro3000]

Agreed with @icco. Since current state of ovirt is deprecated, once the new version is ready we can just create a new version of fog without it and recommend everyone that depends on the deprecated version to not update fog.

[plribeiro3000]

There is also the problem of the version 5 of the api. It would be confuse to have 4 in the name of the gem using the version 5 of the api. =)

[displague]

I started this project a while ago, https://github.com/displague/fog-linode -- I'm sure it would need some rejuvenation. I can carry the torch with some guidance.

[displague]

Is the plan to have an official org like https://github.com/terraform-providers that fog would track out of the box, or is the plan to have each provider parked under the responsible org (I can create this for github.com/linode), or will these providers live under the "fog" org itself?

[plribeiro3000]

@displague I believe the idea is to have all providers under the fog umbrella.
That might help newcomers track changes and help us guide every provider to the same direction.
But @geemus might have other thoughts.

[geemus]

Yeah, at least historically the plan has been to maintain everything under the fog org to facilitate coordinating updates/changes/etc. We can certainly discuss if that seems problematic, but it seems to have worked reasonably well so far anyway.

[dann1]

@mmoll, we created the https://github.com/b0e/fog-one and tried to split out the OpenNebula part, but we had some issues with the auto loading part. https://github.com/b0e/fog-one is already used by https://github.com/b0e/foreman-one (module for Foreman 1.14.3) but only if we additionally load any other fog extension like fog-libvirt. Maybe you can have a short view into the code? If not, maybe i try to step further in autumn. I'm still interested to have working plugins to integrate Foreman and OpenNebula via fog-one. But it seems that we are the only ones, therefor we are happy with a "works for us" solution and it is hard to convince my boss to dedicate more time for this.

Hello, I'll start working on fog-one too. I'm also interested in getting the latest OpenNebula to work with fog-one

[stale]

This issue has been automatically marked stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

[plribeiro3000]

This issue is still active. 😉

[ctreatma]

I'm working on a new fog-linode provider to support Linode APIv4 (the current provider within the fog gem supports APIv3). Our plan is to work on this provider in a different GitHub org and then transfer it over to the fog org; does that still align with your preferred approach? If this provider will eventually live in the fog org, do you have a requirement as to which license should be used for the repo?

[geemus]

@ctreatma develop, then migrate should probably be fine. I think the rest of fog stuff is MIT, so it might be nice to have this follow that for consistency also. What do you think?

[ctreatma]

I'll look into using MIT. We should be able to figure that out soon. To help with that discussion, are there any licenses that are explicitly forbidden for repos within the fog org?

[geemus]

None are forbidden at this time, but the question hasn't really come up before. If you feel a need to deviate, I would just ask you bring it up as a discussion sooner, rather than later, so there are no surprises. Thanks.

[ctreatma]

@geemus thank you for your license recommendations; we are going to use the MIT license for fog-linode to align with the rest of the fog-related repos. For tests, is it OK to use VCR to stub out HTTP interactions rather than set up Fog mocks?

[geemus]

@ctreatma sounds good for licensing. I would tend to think about mocks as more of a user-facing-feature than an internal testing thing (though they get used for both purposes). It's not uncommon for us to have providers that start out without mocks (because it is a lot of of work and difficult), and then add mocks only later (or sometimes not at all). So I think it is reasonable to focus on the implementation first, and worry about mocks later. Beyond that, you should use what works well for you. Some consistency with existing things is valuable, but not if it makes things a lot harder for you to work on. ie VCR should probably be fine if you think that will be helpful.

[ctreatma]

We are ready to transfer our fog-linode provider to the fog org. Is there a formal process for doing that? If so, what should we do to get started?

[geemus]

@ctreatma awesome, glad to hear it. The easiest way we have found is if you could add me, with admin privileges, to your repo. Then I can transfer it into the org and do all the permissions poking/prodding, and then we can work from there. Sound good?

[displague]

@geemus you should have access to the repo. Can you move it straight over?

[geemus]

@displague @ctreatma I believe it should be tranferred, and I invited @ctreatma as an admin. Should I add you as well? Also, could you please add me as a gem owner? I'm unlikely to actually release it, but I like to have access just in case (ie if there was a security flaw or something I needed to respond to quickly across the various gems).

[ctreatma]

@geemus I added you as a gem owner. Please add @displague as an admin for the repo as well.

[geemus]

@ctreatma - thanks. I realized you were not a maintainer-role of the fog-linode team, so I updated that for you. I think that means you should be able to add @displague yourself. (I'd prefer you did, so we can be sure the permissions are all fixed up in case you need them in the future). Just let me know if that doesn't work out though. Thanks!

[ctreatma]

@geemus It looks like I have permissions to add folks to the fog-linode team, but only if they're already members of the fog org.

[geemus]

@ctreatma ah. Well, thanks for giving it a try at least, it's good to know where the edges are (I do this infrequently enough that it's easy to forget). I sent an invite now, just let me know if you need other help here in the future.

[ctreatma]

Thanks @geemus! Could you also invite @sarahelizgray to the org so that I can add her to the fog-linode team as well?

[geemus]

Sure, invite sent.

[HeroesLament]

Could any effort be made to update vCloud Director?