search

concourse / semver-resource

automated semantic version bumping
Apache License 2.0
97 stars 105 forks source link

[swift] make initial version optional #111

Closed taylorsilva closed 4 years ago

taylorsilva commented 4 years ago

Fixes concourse/semver-resource#21

This is the smallest change I could make to fix this issue. I'm unable to run the "unit" tests because I do not have access (or have personally worked with) an OpenStack environment.

The swift driver is actually the only driver with a constructor (NewABC()) function. The other drivers are constructed in FromSource() where there is a copy of the if..else this commit adds.

jomsie commented 4 years ago

So just to be super safe (and not knowing how many users use the swift semver), I'm currently getting a local deployment of openstack swift running in docker... Just trying to get the python swift client cli working on macos now, but i've got some python issues :D

Rabbit hole!

edit: got swift running locally, got a version file uploaded to a swift container, built this pr as a docker image, uploaded to hub, now just configuring the resource

edit: got stuck cause the docker file auth version might be older than golphercloud supports.. looks like golphercloud only supports v2 and v3, and those need a keystone server?

that might be a good docs pr for the semver resource, v1 auth not supported?

gonna revisit this on freedom friday perhaps!

jomsie commented 4 years ago

So just an update to the identity versions that gophercloud supports, looks like openstack technically has a v1, but

You’re probably wondering why Keystone does not implement a “v1” API. As a matter of fact, one exists, but it actually predates OpenStack. The v1.x API was an extremely small API documented and implemented by Rackspace for their early public cloud products.

With the advent of OpenStack, Keystone served to provide a superset of the authentication and multi-tenant authorization models already implemented by Rackspace’s public cloud, Nova, and Swift. Thus, Identity API v2.0 was introduced.

Identity API v3 was established to introduce namespacing for users and projects by using “domains” as a higher-level container for more flexible identity management and fixed a security issue in the v2.0 API (bearer tokens appearing in URLs).

So I think "all identity versions" is fine for saying it supports v2 and v3 only, since v1 isn't really a thing? The readme probably doesn't need updating.

Edit: I'm going to maybe move this investigation work out of this PR, this PR looks good to me btw 😅