134: add inventory service and clients (sans auth) #86
Conversation
JettTech
changed the title
| // Store latest inventory record in memory | ||
| let mut in_memory_cache = HoloInventory::from_host(); | ||
|
|
||
| let one_hour_interval = tokio::time::Duration::from_secs(3600); // 1 hour in seconds |
There was a problem hiding this comment.
@Holo-Host/developers - I'd like to open a discussion about what duration we think is appropriate for a regular inventory check. I put it to 1hr to start.. but would like to surface this as a question and come to an agreement as a team.
There was a problem hiding this comment.
An hour is fine. It'll surface the changes we're looking for within a reasonable timeframe. We're not looking for realtime updates, and given that we're only sending the inventory when it changes from the last run, we're not wasting any capacity storing redundant copies. Ideally, we'd have a configuration file for the agent and this would be tunable. A constant is fine til we have that I guess.
Was on the same page and did so over the weekend. Glad to see you like the update! :D |
| // Store latest inventory record in memory | ||
| let mut in_memory_cache = HoloInventory::from_host(); | ||
|
|
||
| let one_hour_interval = tokio::time::Duration::from_secs(3600); // 1 hour in seconds |
There was a problem hiding this comment.
An hour is fine. It'll surface the changes we're looking for within a reasonable timeframe. We're not looking for realtime updates, and given that we're only sending the inventory when it changes from the last run, we're not wasting any capacity storing redundant copies. Ideally, we'd have a configuration file for the agent and this would be tunable. A constant is fine til we have that I guess.
| }) | ||
| .await?; | ||
|
|
||
| inventory_service |
There was a problem hiding this comment.
There's no point in sending the inventory back unauthenticated. We need to be able to tie it back to the registration info in a consistent/programmatic manner.
We'll have the migration pre-check tests/results to provide info on legacy systems in a bad state. I don't want us to collect legacy cases in the new codebase. The pre-check stuff can contain all of that and we can just ditch the whole crate at a later point.
There was a problem hiding this comment.
Got it. I understood from the last talk between you and @steveej, that there would be cases wherein we would send unauthenticated info about the host. Is this a misunderstanding, or has there been an update?
Either way, I'll remove this unauthenticated call. 👍
There was a problem hiding this comment.
@steveej was going to write a list of calls he felt needed to be unauthenticated a few weeks ago so that we could review it in tangible terms, rather than the abstract terms we were talking on the call. That didn't happen, so I've made the executive decision that the inventory will be authenticated and that the results of the pre-migration checks (yet to be developed) may be unauthenticated (especially as the latter has a limited shelf life).
Yes, I agree that we should probably have this be configurable from the onset. I'll add an env var for this. :) |
…ory service call; fix logs
Closes #134
NB: In the name of smaller PRs, I've separated out the tests from this PR. To review the tests, checkout out pr #87.