Replies: 1 comment 4 replies
-
|
I still prefer Option 2 because it's easier for myself to understand the similarities and differences. But that's my opinion that I won't impose on folks. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is a follow-up thread for https://github.com/lyft/cartography/pull/1219/files/4accca82017477d772aa2a65cddb62869931eb6d#r1309246010.
We're refactoring the AWS NetworkInterfaces to use the cartography data model and are needing to handle an interesting case. A NetworkInterface node's properties can come from multiple sources:
Each of these AWS API calls contains different properties that we would like to unify in a single NetworkInterface node. To represent this using the cartography data model, we create a subclass of CartographyNodeSchema for each potential data source. For example:
EC2NetworkInterfaceSchemarepresents a network interface as known by thedescribe-network-interfacesAPI. This class API call includes fields not returned by any other API call such aspublic_ipandrequester_id.EC2NetworkInterfaceInstanceSchemarepresents a network interface as known by thedescribe-instancesAPI.The end result is that after the cartography network interface and EC2 instance sync jobs run, the resulting graph will have NetworkInterface nodes with properties that are merged from all above sources. This works as long as the
idfields match up.We've identified 2 ways to represent
CartographyNodePropertiesclasses to handle this:EC2NetworkInterfaceNodePropertiesandEC2NetworkInterfaceInstanceNodePropertiesclass:I prefer option 1 because it is more explicit even though there is duplication. I don't think we should create sub-sub-classes of items in https://github.com/lyft/cartography/tree/master/cartography/models/core, and I think we should prefer composition over inheritance.
It will get complicated to handle cases using a class hierarchy where a NetworkInterface's "secondary API" like
describe-instancesincludes more fields than its "primary API" (describe-network-interfaces), and vice versa.Here's how I think of it: a
CartographyNodeSchemaobject is composed of several other objects including aNodePropertiesobject. I don't want to need to think about any hierarchy or nesting structure beyond this.Beta Was this translation helpful? Give feedback.
All reactions