adds a command to migrate a db from bolt to etcd and visa versa. there
is no promise that the options/functionality will not change, hence the
'beta' note. obviously there is also no guarantee that there will never
be any data loss.
after several manual tests, i do have a high level of confidence in the
functionality presented.
* Bolt to kv/bolt
* Remove unused code
* Remove unused roles code
* Remove unused duplicate Makefile
* Clean up bolt implementation and start layering in an interface for another store
* Layer in kv interface
* Continue layering in kv interface
* Remove circuitbreaker things
* Move cell stuff out
* Convert cell logic to kv interface
* Start adding config logic to kv interface, likely will remain bolt only
* Get to compile with bolt kv before moving too far forward
* Start removing dead dashboard code
* Add generic kv implementation for dashboards
* Convert layouts to kv interface
* Migrate mappings to kv layer
* Migrate org_config to kv layer
* Migrate organizations to kv layer
* Migrate servers to kv layer
* Migrate sources to kv layer
* Migrate users to kv layer
* Start removing unused migration logic
Since there is a migration path for users via updating to 1.7.x line then to 1.8, there isn't any real reason to continue supporting migrating from a version ~2 years old.
* Cleaning up bolt dead codes
* Re-add disabled code
* Migrate tests over to kv layer
* Migrate config to kv layer
* Create default organization
* Remove etcd for now
* Improve new client and new service implementations
* Uncomment bolt build tests
* Add layouts test
* Add more dashboard tests to kv
As previously implemented, OrganizationConfig was a global
object. This refactor adds the organization id to context for
every request, even when auth is disabled, so that org id
can be used to get/update an organization config.
Along those lines, this also removes OrganizationConfigStore
.Initialize and replaces .Get with .FindOrCreate, handling
the creation of organization configs upon first attempted
access.
Co-authored-by: Jared Scheib <jared.scheib@gmail.com>
Add diff check to Organization UsersStore Add tests
Previously, a users super admin status was disregarded in the Add
facade. This was problematic when new users were added with a super
admin status, because they would not be granted the status. This created
an odd user experiece.
Previously, canned dashboards were global to the application. When
organizations were introduced, we scoped layouts under a specific
organization. This was done without consideration to the `canned`
layouts which are more global than a specific organization and likely
apply an an application level. Since the layout did not have any
organization associated with it, it was filtered out of the list of
results that one would see for `GET /mappings`.
This commit allows users to retrieve layouts that are stored in the
canned store that do not have an organization associated when the user
requests `All` layouts for an organization.
Future work for this is outlined as a comment in the commit.
Previously, the organizations store did not check to see if the user
that a user was being "added" had a role in the organization, it simply
filtered out a users roles that did not belong to that organization and
blindly appended the new ones that were supplied.
This resulted in users being able to change another users role during
new Add request for the same user.
Previously, when users were updated, we did not use the fields on the
user that was being persisted. As a result, the API responded with the
attribute being set, but the updated values were not actually stored in
bolt. This was not noticed previously because SuperAdmins had raw access
to the UsersStore
Pavel Zavora
greg linton
Greg
Delmer
Alirie Gray
Jared Scheib
Michael Desa
Jared Scheib