add a ibmcloud endpoint

[atheurer]

Looking to have the ability to do something like in our endpoints section of the one-json:

"endpoints": [
    {
      "type": "ibmcloud",
      "settings": {
        "api-key": "path-to-api-key",
        "user": "root",
        "userenv": "stream9"
      },
      "instances": [
        {
          "engines": [
            { "role": "client", "ids": [ 1 ] }
          ],
          "config": {
            "profile": "gx3-16x80x1l4",
            "name": "my-instance-1",
            "geography": "North America",
            "region": "Dallas (us-south)",
            "zone": "us-south-2",
            "resource-group": "Default",
            "image": "ibm-centos-stream-9-amd64-11",
            "settings": {
              "osruntime": "podman"
            }
          }
        },
        {
          "engines": [
            { "role": "server", "ids": [ 2 ] }
          ],
          "config": {
            "profile": "gx3-16x80x1l4",
            "name": "my-instance-1",
            "geography": "North America",
            "region": "Dallas (us-south)",
            "zone": "us-south-2",
            "resource-group": "Default",
            "image": "ibm-centos-stream-9-amd64-11",
            "settings": {
              "osruntime": "podman"
            }
         }
        }
      ]
    }
  ]
}

Users would need to provide a api key to access ibmcloud.
We will probably want a lot of defaults for profile, geo, region, zone, resource-group, etc.
This endpoint may get refactored to be a general-public-cloud thing but trying to keep it simple with one for now

[k-rister]

I have no idea if this is possible or not, but I would be very interested in seeing if we could implement this using something like terraform

[atheurer]

Eventually I'd like to use that, but for first pass I want to keep it as simple as possible.

[k-rister]

Eventually I'd like to use that, but for first pass I want to keep it as simple as possible.

I think it is an interesting question about which approach is actually more simple. I don't think one or the other is a given, it might take some brief research to make that call.

[atheurer]

I'll take a look at terraform.

If we use something like terraform, I suspect it's going to be to the user's benefit to include a completely unmodified terraform config into the run.json, and then we need some sort of mapping in the run.json to assign crucible engines to resources (VMs) that were generated via terraform. Not sure how easy this will be, as we need crucible to properly interpret parts of the terraform config, like the VM's name, in order to make the engine assignment work.

There are a few other items I hope we can achieve:

• some sort of watchdog to delete cloud resources if a crucible job dies (don't want to keep paying for VMs)
  • or maybe there's a way to have a terraform reservation automatically expire after N minutes
• crucible tells us how much the cloud resource cost to run the job
• networking:
  • endpoint manages ssh tunnels to VMs so that a VMs can reach a crucible controller that's behind a VPN
  • firewall mgmt for the cloud reservation, to limit VMs' new connections to just the crucible controller

[k-rister]

I could be wrong, but it seems like it would be a very high barrier to expect the user to construct a terraform config file that meets all the requirements that crucible has.

I was mostly envisioning our endpoint having a "traditional" interface that is similar to the other endpoints but then on the back end we take that input and build terraform config files. That way the user interface is similar across all endpoints but the work to produce the endpoint is offloaded to another tool that happens to be (mostly or somewhat?) cloud agnostic and would provide support for many different cloud environments with hopefully very little scaling effort.

[atheurer]

I guess it depends on how much control you want the user to have on the cloud config. On your approach, I do wonder if taking that idea and going even further by enhancing remotehosts endpoint to just take a few more inputs and have it handle the cloud deployment (via terraform) would be preferable. In the remotes[] section, instead of each remote subsection having a host/IP, one could include some kind of cloud-resource object which described the profile/vm-type, the boot-image, etc.

[k-rister]

I think it depends on just how much terraform "shields" you from directly interacting with the cloud. For example, is it strictly a configuration tool or does it replace some of the other associated functionality like accessing logs?

There is a lot of stuff that remotehosts is doing beyond just configuring and launching the engines such as log collection, image management, endpoint cleanup, etc. so I wonder how that would all fit together. Could it all be done through terraform? Or is it going to require a mix of terraform for config management + cloud specific tools for some of the other stuff? If it gets "too hybrid" I would be weary of trying to shove it all into one place out of fear of it becoming too unwieldy (especially if eventually trying to make it multi-cloud).

It might be worth pointing out at this time that what we are talking about using terraform for might have a lot more in common with the OSP endpoint than remotehosts since remotehosts is assuming a live/running OS instance (VM or baremetal) already being online and available.

[k-rister]

@atheurer Is it fair to say that you are working on this and it should be in "In Progress" state?