Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am trying to move flexgroup constituents from one aggregate to another, but when I try to find information on the constituent prior to a moving it, I am getting an error. Here is the constituent's information as per the system's CLI:
yankee-mgmt::*> vol show -fields instance-uuid -volume flexgroup_test__0001
vserver volume instance-uuid
------- -------------------- ------------------------------------
ruth flexgroup_test__0001 ac3e03a1-f04c-4fce-98de-0f94e8196aee
The REST informational call of https://yankee-mgmt/api/storage/volumes/ac3e03a1-f04c-4fce-98de-0f94e8196aee returns the following:
{ "error": {"message": "entry doesn't exist", "code": "4", "target": "uuid"} }
With the above in mind, why isn't the REST call finding the constituent information?
Solved! See The Solution
1 ACCEPTED SOLUTION
Drew_C has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have been testing on a lab system and it looks like manipulating a constituent volume by REST is not possible. REST calls look up volumes via a REST specific internal table. I checked and constituent volumes are not propagated on it nor supported for use. I tested and get the same result with CLI passthrough.
I will verify this with Engineering and then write up a kb article discussing it and link it here.
1 REPLY 1
Drew_C has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have been testing on a lab system and it looks like manipulating a constituent volume by REST is not possible. REST calls look up volumes via a REST specific internal table. I checked and constituent volumes are not propagated on it nor supported for use. I tested and get the same result with CLI passthrough.
I will verify this with Engineering and then write up a kb article discussing it and link it here.
