rackspace / gophercloud Goto Github PK

Remove all private repo-related documentation.

Also, massage and incorporate this body of text, so that people know (or, at least, have a better idea of) how to contribute to the project. That way, I don't have to keep searching and tweaking on a case-by-case basis this text for interested people.

If you're still willing to contribute to gophercloud, our new
multi-provider API for Go to replace Gorax, I'd like to let you know
some of the details.

1) Our new home is https://github.com/rackspace/gophercloud

2) We use huboard.com for work tracking, which means we use the issue
tracker a lot.  See http://huboard.com/rackspace/gophercloud/board 

3) I have several pull requests (now since merged) which, I *think*,
illustrates well how to go about adding new functionality to the
project.  For example, here are two related commits (both part of a
single PR, but they don't have to be) that might be of interest in
showing how I add functionality in tiny pieces:

  https://github.com/rackspace/gophercloud/commit/e3b2d7a79e372b9be08095a5774cf588c94f6a92

  https://github.com/rackspace/gophercloud/commit/286e4de1c95161c9ec6e756efe7c6f7a3bab2615

Sometimes, tiny pieces aren't possible (either due to my own lack of
practice in this area, or due to technical invariants enforced by the Go
compiler itself).  Here's a PR that is rather on the large side by my
standards, but I wasn't able to reduce it to smaller pieces (or missed
opportunities to do so).  Note, however, that the commits comprising the
PR are related, and except for one, relatively self-contained.

  https://github.com/rackspace/gophercloud/pull/46

4) We have a mailing list where design or other developer-related
discussions happen.  You can join the group here:

  https://googlegroups.com/group/gophercloud-dev

5) We are using a "merge to trunk" style of development for the time
being.  This means that contributors DO NOT need to seek code review
approval from me or any other developer to merge changes to master.
What determines whether you are allowed to merge to master is that all
acceptance tests run, and all unit tests run.  We still use
feature-branches to keep things organized though, and we still e-mail
pull requests to the gophercloud-dev group as a courtesy (it doubles as
a status report as well).  The idea is that actionable PR feedback is to
be taken as high-priority backlog items, and should be filed and acted
upon as such.

Some explanation might help as to why I'm taking this rather non-obvious
approach to managing commits.  First, the "review code before
committing" approach is useful only when you have a sufficient body of
reviewers that feedback happens rapidly.  Since we're all busy with
different primary jobs, and we're in different time-zones, waiting for
feedback on a review will delay progress.  Second, we need to think of
supporting contributors from outside of Rackspace as well.  Third, if
the build breaks, it's (ultimately) every developer's job to fix it in a
timely manner.

(Speaking of which, I should get a Travis CI integration ticket up, so I
don't forget.)

Please let me know if this information is helpful, and would love to see
an additional contributor come on-board so I can work out the bugs of
the development process.  Let me know if there's anything not explained,
or feel free to dive in.

Thanks!

Clarification required on what this maens. I suspect this simply means designing test cases to ensure the library and endpoints properly support IPv6 addresses.

Please add a license. I assume this is meant to be open source. If that is the case the license should be included.

Currently no ability exists to create a new image (as opposed to using an existing, running instance and create an image based on that instance). There also should exist ability to add new image records and upload the associated binary so users can start from scratch where necessary.

I've forked this repo and added the ability to do the above (see the add-create-upload-image branch here: https://github.com/TranscendComputing/gophercloud).

As a side issue also fixed an issue where listing images on a V2 images API failed for incorrect URL (/v2/images/details does not exist, though v1/images/details does).

I'll issue a pull request for these as soon as I add the testing facilities. This issue is just for notice to everyone so they don't need to rush to add the facility if they need it.

Provide an Access.CloudServerApi() method which, if a service catalog entry compatible with cloud server API exists, returns a CloudServerApi interface. Otherwise, return an error.

This entails a small amount of API redesign.

Rather than submit this as a pull request, the simple way is to run this command in the repo:

find . -name "*.go" -exec gofmt -w {} ;

I prefer this method to using "go fmt" since I can also see what it will do with:

find . -name "*.go" -exec gofmt -d {} ;

This seems to be a better name; it's more descriptive, and follows conventions set by OpenStack.

Original bug can be found here:

racker/gorax#32

Since Gophercloud is built using software borrowed from Gorax, if it's a legit Gorax bug, it will be a bug in gophercloud as well.

This will involve an API redesign to meet the new expectations.

If the authentication token is about to expire, or has already expired, AND if enabled by the client application, attempt to re-authenticate before performing the intended operation.

Possible plan of attack: make Authenticate() idempotent; if already authenticated AND token is still valid, then Authenticate() just returns its previous results.

Alternatively: Define Authenticate() in terms of Access.Reauthenticate(), and make Access.Reauthenticate() idempotent. This seems a better way to factor things.

Rackspace now has a single global identity system, obviating the need for separate "rackspace-us" and "rackspace-uk" providers. I suggest adding a global "rackspace" provider, and eventually removing the existing ones.

Requires clarification on what this means from Glen.

Hoping we can side-step the huge can of worms here...

There's been flip-flopping over whether it's called a "tenant" or a "project".

In the Identity V3 API, it is officially a project.

I'm to blame here for proposing a patch which included TenantName, but should we call it TenantName or ProjectName?

I think we should call it "Project", because (1) it makes more sense to humans and (2) it is the V3 word. Even if it currently maps to something in the V2 API called "tenant" :-)

I think everything is new enough that we can easily switch now without needing a compatibility shim.

For example, the ListServers method on genericServersProvider will only ever retrieve a single page.