Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Asset Manager] Add getServices to public client #167342

Closed
Tracked by #154078 ...
jasonrhodes opened this issue Sep 26, 2023 · 3 comments · Fixed by #167692
Closed
Tracked by #154078 ...

[Asset Manager] Add getServices to public client #167342

jasonrhodes opened this issue Sep 26, 2023 · 3 comments · Fixed by #167692
Assignees
Labels
Feature:Asset Manager Team:Observed Asset Management Label used for engineers working on various parts of observed asset management

Comments

@jasonrhodes
Copy link
Member

Acceptance Criteria

  • assetsClient available to dependees, on server and browser
  • assetsClient.getServices method exists (accepting the same parameters as the associated REST API) on server and public clients
  • Plugin docs updated to reflect new API availability
  • options.parent that exists now should be solidified for use with signals and assets source consistently
@jasonrhodes jasonrhodes added Team:Observed Asset Management Label used for engineers working on various parts of observed asset management Feature:Asset Manager labels Sep 26, 2023
@jasonrhodes jasonrhodes self-assigned this Sep 26, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/observability-asset-management (Team:Observed Asset Management)

@jasonrhodes
Copy link
Member Author

@klacabane I'm looking at the server client + REST API and they both accept an options.parent value, but the way the queries are designed, it looks like you'd need to pass a fully-formed EAN value if we're reading from assets, whereas you'd pass just a hostname if we're querying from signals.

I'm considering accepting only an EAN there and then parsing it in the server method and attempting to construct relevant signals-based queries based on the kind, what do you think? Did you attempt that and bail or just go for what worked well enough for now? (Either one fine!)

@klacabane
Copy link
Contributor

Did you attempt that and bail or just go for what worked well enough for now?

I may have only considered a world where you use assets or signals, so consumers provide the appropriate value depending on the active mode. Only accepting ean sounds good to me, the format can be parsed to provide filters in both mode

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Asset Manager Team:Observed Asset Management Label used for engineers working on various parts of observed asset management
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants