This can be used in tests to get access to a controller that behaves
just like a dev controller but doesn't require the normal Command bits
(UI, etc).
This can be enhanced over time as needed; for now it's pretty simple but
it's good enough to be used for API tests. A simple project create/read
API test is added as well, which serves to show the programmatic model
(as well as test those functions at the API level).
* Renamed fakeRepo to mockRepo
* Changing around TODOs to capture current plans with the code.
* Remove the repo interface and use a real DB for tests.
* Fixed a few tests.
* Adding checks for properly formatted identifiers.
* Updating code to account for recent merges. Relaxing some restrictions on what an id can look like.
* Added small comment explaining why RegisterGrpcGatewayer interface exists.
* Move project service up a call level.
Long term I think it would make sense to define these services even higher up the call stack, potentially at the initialization of the controller server, near where the DB is initialized.
* Making these fields align with those in the resources under hosts/...
* Hard code the service initialization in the handler registration code.
* Regenerate project related code proto code.
* Removing type field for project.
* Adds basic project handling in CLI/SDK (#47)
* Adds SDK for creating and reading projects
* Reorganizes a bit
* Adds CLI for creating and reading projects
* Fixes some some generation bugs
* Adds redirect support for default org ID
* Fix protobuf import references being moved.
* Update client test to look for "orgs" and "projects" instead of "org" and "project"
* Update expected segments test
* Fix setAddr handling when default organization is in use
* Set client in target after create or read
Co-authored-by: Jim Lambert <jimlambrt@Jims-MBP-3.home>
Co-authored-by: Jim <jlambert@hashicorp.com>
Co-authored-by: Michael Gaffney <mgaffney@users.noreply.github.com>
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This was generating fine before but it makes it explicit in the proto
and it avoids weirdness where the protobuf tag will say a name is
something like requestId where the json tag says it's request_id. This
way they line up.
One thing not honoring this properly is TraceId. I don't know why the
JSON tag being generated doesn't match even when explicitly set here.
For now I'm just manually fixing it.
* Rename FriendlyName to Name
* Standardize on connection parameters for the server being addr
This syncs up WATCHTOWER_ADDR and -addr (formerly -address) and frees up
-address to be used in resources (which it is).
* Add description fields
Jeff Mitchell
