-
Notifications
You must be signed in to change notification settings - Fork 5k
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
CRP and NRP Swagger are not accurate for NIC/IPConfiguration's primary fields #305
Comments
@deepakswifty and @dihan0604 please respond with a fix or an explanation which could be used to make the correction to the spec. |
Ping? |
@markjbrown can you or someone else from networking comment on this? |
@deepakswifty, Hi Deepak, could you take a look? This is not express route cmdlets,I am not familiar with it. |
Ping? |
Hi @colemickens, sorry for the late reply. we have just added the primary field for ipconfguration. It will be under a feature flag. I would say the algo should be that (for nic and ipconfiguration), if the primary flag is not set, treat it as primary. If there are multiple nics and ipconfiguration then the primary flags for all nics and ipconfigurations will be set |
Makes sense. Will this /always/ be behind a feature flag? How are feature-flagged portions of the API handled when it comes to the Swagger spec? Is there anyone from the CRP side we can talk to so that they will add the same flag is supposed to be there for the NIC in the VM Instance response? Or is that added now as well? |
Makes sense. Will this /always/ be behind a feature flag?
How are feature-flagged portions of the API handled when it comes to the Swagger spec?
Is there anyone from the CRP side we can talk to so that they will add the same flag is supposed to be there for the NIC in the VM Instance response? Or is that added now as well?
|
Thank you for the explanation @DeepakRajendranMsft. This definitely gives me enough information to write a conformant implementation. That having been said, I would suggest that always returning the primary field in the single-nic or single-ipconfig scenario is preferred. As is, I have to write more heuristic code-- (is there more than one nic, okay, then just take that, if not loop through the nics and look at the primary flag. then fetch that nic and check if there are more than one ipconfig, if not, just use the first one, if so, look through all of them and examine primary flag). I can write the code much more generically if I just loop through them regardless of how many there are, looking for the |
@colemickens thanks for feedback. we always want to maintain the customers input (even on the output). thats why its optional. @markjbrown for documenation |
@DeepakRajendranMsft wouldn't a feature flag be part of a preview api-version? I wouldn't imagine they would be part of a non-preview api-version. Beyond that, I think the only other thing we can do is to include a comment in the description of the operations or on the model calling out the fact that the feature is there, but not available in all subscriptions. Perhaps, also including some information on how to be an early adopter of the feature. |
Is there an estimate for when the ip-config primary flag will no longer be behind a feature flag? |
@DeepakRajendranMsft @devigned Can we re-sync on the new field that was exposed from NRP? In particular, has it been added to any published Swagger specs? If not, when will it be? And when will it no longer be behind a "feature flag"? |
Ping @DeepakRajendranMsft , @devigned for the above questions. Is this stuff actually consistent between the services are returning, documented to return, and what is actually in the Swagger spec? Both the CRP field and the NRP field? |
Summary:
Thanks to @DeepakRajendranMsft for providing this information. |
@colemickens thank you for adding the summary of the discussion! |
So I am looking to fix hashicorp/terraform#6514 Reading through the code I justed realize there are two Primary flags. It is not clear to me. Can I choose to set either? Give the choice I rather put it on the interface and not the ip config. |
Looks like I am reading this wrong. We need to set the primary doing the CRP. |
Update ADM API Spec
The core details are here: Azure/azure-sdk-for-go#259 (comment)
The Swagger spec for Compute Instance -> NetworkProfile NIC -> primary is not correct -- in that [someone] is not populating the "primary" field for an Interface in my VM's NetworkProfile.
The Swagger spec for Network's Interface -> IPConfiguration -> primary field does not exist.
The net result of this is that I can NOT accurately write code to say... place a VM in a load balancer backend pool because I have no way of determining which NIC is primary, or which ip configuration on the NIC is primary.
I'm currently "working around" this by assuming that there is only one NIC and only one IP Configuration... which is probably fine for my use case, but we should still fix this.
The text was updated successfully, but these errors were encountered: