6750 Add support for post-install LLDP configuration #7132
Conversation
6751 Add support for extracting LLDP neighbor information
nexus/src/app/lldp.rs
Outdated
| PortId::MacAddress(mac) => format!( | ||
| "{:02x}:{:02x}:{:02x}:{:02x}:{:02x}:{:02x}", | ||
| mac.a[0], | ||
| mac.a[1], | ||
| mac.a[2], | ||
| mac.a[3], | ||
| mac.a[4], | ||
| mac.a[5] | ||
| ), |
There was a problem hiding this comment.
Should we implement a to_string() method for the mac address type to reduce repetition?
| rqctx: RequestContext<Self::Context>, | ||
| path_params: Path<params::SwitchPortPathSelector>, | ||
| query_params: Query<params::SwitchPortSelector>, | ||
| ) -> Result<HttpResponseOk<Vec<LldpNeighbor>>, HttpError> { |
There was a problem hiding this comment.
When returning a collection, we try to use a paginated response.
| @@ -0,0 +1,178 @@ | |||
| use super::DataStore; | |||
There was a problem hiding this comment.
copyright and license headers?
There was a problem hiding this comment.
I added a license header. I didn't look at every other file in that directory, but none of the ones I did look at had a copyright line. Should they all be updated?
There was a problem hiding this comment.
Probably; but out of scope here I suppose!
| // | ||
| // For consistency across the lldp operations, all use rack/switch/port rather | ||
| // than the uuid. | ||
| // XXX: Is this the right call? The other options being: uuid for all |
There was a problem hiding this comment.
Is it? Should we decide before merging this?
There was a problem hiding this comment.
I think it is, which is why I implemented it this way. The comment was meant to solicit feedback from the reviewers with more API experience - i.e, you. I probably should have made that a github/review comment rather than a rust comment to make that clearer.
There was a problem hiding this comment.
Thanks for clarifying. I think it's fine to use rack_id / switch-port rather than the uuid. I do think it's a little odd that the port is often a path param and the rack is a query param. Was there some particular motivation for that?
There was a problem hiding this comment.
I'm not sure. Having rack/switch/port in the path seems more natural to me, but this was the pattern Ry used in the original stake-in-the-ground API. I don't know if he had something specific in mind, or if it was the result of a quick decision that was never revisited.
There was a problem hiding this comment.
I would suggest using both the rack id and port in the path, and there seems to be at least some precedent for that.
| use omicron_common::api::external::UpdateResult; | ||
| use uuid::Uuid; | ||
|
|
||
| // The LLDP configuration has been defined as a leaf of the switch-port-settings |
There was a problem hiding this comment.
Should this whole thing be //!? It seems like kind of a doc comment, but I'm unsure.
There was a problem hiding this comment.
I meant it to be useful to somebody reading the code, rather than somebody using the API.
| @@ -0,0 +1,132 @@ | |||
| use crate::app::authz; | |||
There was a problem hiding this comment.
Done - again license only.
| @@ -196,6 +196,9 @@ networking_bgp_status GET /v1/system/networking/bgp-stat | |||
| networking_loopback_address_create POST /v1/system/networking/loopback-address | |||
| networking_loopback_address_delete DELETE /v1/system/networking/loopback-address/{rack_id}/{switch_location}/{address}/{subnet_mask} | |||
There was a problem hiding this comment.
it does seem like including the rack-id in the path might make more sense based on this precedent. I'm not sure what @internet-diglett has in mind to wrangle the API, but I infer that's still in the works.
| // | ||
| // For consistency across the lldp operations, all use rack/switch/port rather | ||
| // than the uuid. | ||
| // XXX: Is this the right call? The other options being: uuid for all |
There was a problem hiding this comment.
I would suggest using both the rack id and port in the path, and there seems to be at least some precedent for that.
openapi/nexus.json
Outdated
| "description": "successful operation", | ||
| "content": { | ||
| "application/json": { | ||
| "schema": { |
6751 Add support for extracting LLDP neighbor information