This adds support for tracking and reporting monthly active users for
the purpose of billing. It adds a new API endpoint,
`/v1/billing:monthly-active-users` and new cli command, `boundary
billing monthly-active-users` that can be used to view the monthly
active user counts.
This adds a new accumulating fact table to the data warehouse for auth
tokens. This fact table is used to calculate the number of active users
within a month, where an active user is a user that has at least one
issued auth token within the time range of the month.
This updates the billing repository to use timestmap.Timestamp when
constructing the queries to retrieve monthly active users. This allows
for specifying NegativeInfinity to easily retrieve all monthly active
user counts.
When converting a timestamp.Timestamp for use in SQL, this now correctly
converts the NegativeInfinity and PositiveInfinity constants into the
corresponding `-infinity` and `infinity` SQL constants.
These functions will ensure that UTC time is used for billing queries,
eliminating the need for the repository to set the timezone. This also
means the repository no longern needs a writer.
This adds two sql functions that can be used to access the views to
retrieve monthly active user counts. The functions ensure that any time
calculates are performed in UTC, so that the month bounds align with the
start of the month in UTC.
1. hcp_billing_monthly_active_users_last_2_months() will return monthly
active users for the current and previous month.
2. hcp_billing_monthly_active_users_all() will return monthly active
users for all months. This function can also be provided a start time
and or end time to filter the results to a specific range.
This test started failing now that the data warehouse records a auth
token fact when an auth token is issued and it requires that the auth
token has a user associated with it.
Since this test is testing the interaction with the database directly,
and not via the repository, it by-passes the application checks that
would prevent an auth token without an associated user being inserted.
This test is updated to meet this same pre-condition prior to attempting
to insert into the database.
Now that there is an auth token fact table in the data warehouse, it is
not possible to insert an auth_token with an old public_id even after
that auth_token was deleted, since it now causes a constraint violation
on the data warehouse table.
With the addition of an after insert trigger to the auth_token table,
entries are added to the wh_user_dimension table when auth token's are
inserted with the 'token issued' status. This caused a number of tests
to fail that assumed the user dimension table would be empty prior to
inserting sessions. This introduces a number of changes to the tests:
- In the test setup, auth tokens are not created with an explicit
expiration time and status. The expiration time ensures that the
tokens are 'valid' for the test. The status allows test to make
assertions on tokens in different statuses, and allow the status to
change during the test.
- Tests make the correct assertions on the number of entries in the user
dimension table after test setup.
- User dimension tests modify a user after the standard setup to ensure
that a new user dimension is added when a session is inserted.
This adds a function and after delete trigger to the auth_token table to
ensure that a corresponding auth token fact is updated with the deleted
time and sets the auth token valid time range. The data warehouse will
only be updated if the token that was deleted is in the 'token issued'
status.
This adds a function and update trigger to auth_token to ensure that:
1. If the auth token is updated to the issued state, a auth token fact
is added to the warehouse.
2. If the auth token's approximate last access time is updated, the
corresponding auth token fact is updated with the new time.
Previously the function used to upsert into the user dimension required
both an auth token id, and a user id. However, the user id can be
determined from the auth token, in fact it already was via the
whx_user_dimension_source view. This refactor removes the user id as an
argument, since it is not needed and will not be directly available when
this function is used when populating the new auth token accumulating
fact.
When running the sqltests, sometimes it is helpful to see the full
database container logs, especially when there is an error in a
migration or database setup. However, it also makes it difficult to see
the test results.
This adds a new variable to the makefile to easily toggle the output of
these logs on or off. To run the tests without printing the dtabase logs
use:
DB_LOGS=0 make test
To enable the logs use:
DB_LOGS=1 make test
By default the logs are not printed.
Some of the prepared statement identifies used in these tests exceeded
the identifier character limit. This results in postgres truncating the
name, which is fine for a test, but does result in some noise in the
test output. This change shortens the identifies to eliminate noise like
the following:
psql:/test/credential/vault/credential_vault_library_ssh_private_key_mapping_override.sql:49: NOTICE: identifier "insert_credential_vault_library_ssh_private_key_mapping_override" will be truncated to "insert_credential_vault_library_ssh_private_key_mapping_overrid"
The tests should no longer create notices like these.
This does not currently remove the field from the message on the API but
since it will now always show `pki` it's meaningless and causing
confusion for some users.
* Save and assign hclogger throughout the client cache daemon
* Don't event for errors happening outside of the handlers or tickers.
* Hide and ignore -store-debug and expose the -log-level flag
* test(e2e): Add test to check target's -session-max-seconds
* test(e2e): Add additional test to check new connections are rejected
* test(e2e): Fix test check
* handlers/targets: always return pagination parameters in list
* handlers/authmethods: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/accounts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/authtokens: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentiallibraries: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentials: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentialstores: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_catalogs: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_sets: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/hosts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/managed_groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/roles: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/scopes: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/sessions: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/users: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* chore: update deps
* tests: update sqlmock tests for breaking chg
* tests (handlers): sort grants in checkEqualGrants(...)
sort the expected and got grants in
checkEqualGrants(...) to make the test more
deterministic.
* tests (asciicast): update backspace enc in TestEventMarshal(...)
* fix: Proxy closing listener with 0 connections left
A bug was introduced in `0.15.0` where sessions with max connection counts were closed when the connections left hit 0. This issue was highlighted by a user: https://github.com/hashicorp/boundary/issues/4364. What was happening was when we have zero connections left the proxy code was closing the listener which closed its connections
To fix this:
- `boundary connect -target-id=xx -host-id=xx` command with no connections left will now wait for all connections to be closed and before exiting the session just like it did in `0.14.3`
- As soon as there are no more connections left, the listener will close to stop accepting new connections
- Fix issue where the websocket connection was throwing closing errors during the session teardown.
Timothy Messier
Michael Milton
Jeff Mitchell
Michael Li
Todd
Ikko Eltociear Ashimine
Stan Ryzhov
Johan Brandhorst-Satzkorn
Dan Heath
Jim
Elim Tsiagbey