Skip to content
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

azure.mgmt.containerinstance.ContainerInstanceManagementClient.container_groups list operations returning stale / incomplete resources #2662

Closed
adamcunnington opened this issue May 30, 2018 · 4 comments
Labels
ACS customer-reported Issues that are reported by GitHub users external to the Azure organization. Docs question The issue doesn't require a change to the product in order to be resolved. Most issues start as that RestAPI Service Attention Workflow: This issue is responsible by Azure service team.

Comments

@adamcunnington
Copy link

I have instantiated an authorised azure.mgmt.containerinstance.ContainerInstanceManagementClient object. When i iterate over .container_groups.list() I see the 3 container groups but their instance_view property is None. However, when I call .container_groups.get() the object I get has all the properties populated and I can see the instance_view property.

Therefore, unless this is somehow deliberate behaviour of list/list_by_resource_group, i.e. to return a partial resource, this is a bug.

@lmazuel
Copy link
Member

lmazuel commented May 30, 2018

Hi @adamcunnington
That's a common pattern I see from RestAPI on Azure, that list is listing the common properties, and you need an additional get to get the detailled property (see #573 for instance). So I would consider this more a lack of features than a bug actually. But let me send an email to the RestAPI service team, to see if they have guidance or suggestion here.
Thanks,

@lmazuel
Copy link
Member

lmazuel commented May 30, 2018

Hi @adamcunnington
I got confirmation from the team, it's not possible yet because that's a very expensive operation. So let's say the list returns 100 container groups, this might take more time than a reasonable Rest call. Note that you can parallelize the get calls to be fast if necessary. We are also working on the async version of this SDK, which would do the parallelize code simple to write.
Note that the ACI team noted your feedback, and said "If this becomes common, we will find ways to implement." so thank you for the feedback :)

I keep this issue open until I'm able to suggest at least some async code to do that.

@lmazuel lmazuel added Docs question The issue doesn't require a change to the product in order to be resolved. Most issues start as that RestAPI labels May 30, 2018
@adamcunnington
Copy link
Author

Thank you for confirming. I don't mind this behaviour (although it's not typical behaviour for REST APIs) - it's just not documented as far as I can see. The description at https://docs.microsoft.com/en-us/python/api/azure.mgmt.containerinstance.operations.containergroupsoperations?view=azure-python is basically identical for list and get operations.

@lmazuel
Copy link
Member

lmazuel commented May 31, 2018

Hi @adamcunnington
I agree it's not documented, since get and list return the same object, it's not obvious that the ones from list with be None always. I take a note to improve that as well.

@lmazuel lmazuel added the ACS label Jul 24, 2018
@bsiegel bsiegel added the Service Attention Workflow: This issue is responsible by Azure service team. label Sep 26, 2018
@azure-sdk azure-sdk added the customer-reported Issues that are reported by GitHub users external to the Azure organization. label Sep 24, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ACS customer-reported Issues that are reported by GitHub users external to the Azure organization. Docs question The issue doesn't require a change to the product in order to be resolved. Most issues start as that RestAPI Service Attention Workflow: This issue is responsible by Azure service team.
Projects
None yet
Development

No branches or pull requests

4 participants