-
Notifications
You must be signed in to change notification settings - Fork 14
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
feat(models): add new package to handle protobuf translation #267
Conversation
Codecov Report
@@ Coverage Diff @@
## main #267 +/- ##
==========================================
+ Coverage 65.00% 65.21% +0.20%
==========================================
Files 19 19
Lines 1366 1374 +8
==========================================
+ Hits 888 896 +8
Misses 434 434
Partials 44 44
|
Signed-off-by: Boris Glimcher <Boris.Glimcher@emc.com>
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 the changes are towards the right direction.
Is it possible instead of writing little code for all objects to just first write all the code or significant part of it just for one or two objects (e.g. VRF and SVI or LB and BP) so I can review the code better and be sure that I am agreeing with the translation approach ?
That would really help me reviewing the code
This change defines interfaces. With new package, New and To functions and enough code to understand the new structure. The content of each function for specific transformation will come in subsequent PRs |
) | ||
|
||
// Bridge object, separate from protobuf for decoupling | ||
type Bridge struct { |
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.
seems like we can also add interface here
) | ||
|
||
// Port object, separate from protobuf for decoupling | ||
type Port struct { |
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.
seems like we can also add interface here
) | ||
|
||
// Svi object, separate from protobuf for decoupling | ||
type Svi struct { |
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.
seems like we can also add interface here
) | ||
|
||
// Vrf object, separate from protobuf for decoupling | ||
type Vrf struct { |
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.
seems like we can also add interface here
Approach looks fine overall. The only alternative I think worth considering is using this copier library. It would save you a bit of boilerplate code by defining the field mapping in the struct itself. However, this would only work from pb to struct, not the other way. |
opened #269 I was thinking also marshaling with json for auto-copy approach... will investigate this |
Signed-off-by: Boris Glimcher Boris.Glimcher@emc.com
This is just a first draft and will be amended later on to include more fields and fix Todos...
There are 4 objects:
LogicalBridgeSpec
BridgePortSpec
SviSpec
VrfSpec