-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Endpoint] EMT-65: make endpoint data types common, restructure #54772
Changes from 1 commit
6577ba0
5127ff5
1128056
ea26d3d
d96e1f9
49d745c
f5630f2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,58 @@ | ||
/* | ||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
* or more contributor license agreements. Licensed under the Elastic License; | ||
* you may not use this file except in compliance with the Elastic License. | ||
*/ | ||
|
||
export class EndpointAppConstants { | ||
static ENDPOINT_INDEX_NAME = 'endpoint-agent*'; | ||
} | ||
|
||
export interface EndpointResultList { | ||
// the endpoint restricted by the page size | ||
endpoints: EndpointData[]; | ||
// the total number of unique endpoints in the index | ||
total: number; | ||
// the page size requested | ||
request_page_size: number; | ||
// the index requested | ||
request_page_index: number; | ||
} | ||
|
||
export interface EndpointData { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nnamdifrankie Is there a PR that defines this struct in ECS that the Endpoint team agreed upon? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This our current working agreement. We will need another revision it would seem, now that we have more experience. Once we do this we can make the changes on all sides. https://docs.google.com/spreadsheets/d/1ROweh2FrHxEROcXPKWV7bvGEjg2baSA4W5dNxI5yOw8/edit#gid=0 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nnamdifrankie Awesome! Can you condense that into a PR that's in the ECS yml format to https://github.com/elastic/endpoint-app-team/pulls - this is where we're tracking all the ECS data formats that the endpoint will be sending. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the format should be in source control and easily found by everyone on the teams to make comments about the structure and format. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
machine_id: string; | ||
created_at: Date; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Q. I think this is a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do you think it is a str, is it because of the format. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nnamdifrankie JSON does not have a way to serialize/de-serialize dates. They will come across as Strings if the value of attribute is an actual JS Date object (defaults to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks @nnamdifrankie . So back to the type - what will it be? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @paul-tavares I think we can map it at time of use or parameter definition. Once the other PR is merged and the type definition is available. Remember that we use it here as output, so we can map it on output or the caller can. Also recall that this is an api route and can be called by any client curl, front end e.t.c so it is not critical here for us and makes no difference. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry @nnamdifrankie , I'm confused. Are you leaving the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I decided to define it a date so that it is explicit that when data is deserialized into that EndpointMetadata object the value of that field should be a date type. Is this satisfactory? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's fine. |
||
host: { | ||
name: string; | ||
hostname: string; | ||
ip: string; | ||
mac_address: string; | ||
os: { | ||
name: string; | ||
full: string; | ||
}; | ||
}; | ||
endpoint: { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think |
||
domain: string; | ||
is_base_image: boolean; | ||
active_directory_distinguished_name: string; | ||
active_directory_hostname: string; | ||
upgrade: { | ||
status?: string; | ||
updated_at?: Date; | ||
}; | ||
isolation: { | ||
status: boolean; | ||
request_status?: string | boolean; | ||
updated_at?: Date; | ||
}; | ||
policy: { | ||
name: string; | ||
id: string; | ||
}; | ||
sensor: { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should change this to |
||
persistence: boolean; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe we will only have persistent endpoints with the new product. Perhaps capturing version number. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we can discuss this further with the larger team. As per @kevinlog we are going to peer down the data and change some of the references. Will involve us changing our generator too, so may not want to tackle that here. We just want to show the list. |
||
status: object; | ||
}; | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to move a
Class
to thistypes.ts
file? I don't see the FE needing itThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nnamdifrankie see my prior comment here. I don't think you should have a Class in this file (maybe you meant
interface
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @nnamdifrankie is defining constants here, not types necessarily. So I would say that maybe we could move this somewhere else, if we're trying to have this file contain and export types for the app.