> Takashi Natsume <natsume.taka...@lab.ntt.co.jp> writes: > >> In some compute REST APIs, it returns the 'marker' parameter >> in their pagination. >> Then users can specify the 'marker' parameter in the next request.
I read this as you saying there was some way that the in-band marker mapping could be leaked to the user via the REST API. However, if you meant to just offer up the REST API's pagination as an example that we could follow in the nova-manage CLI, requiring users to provide the marker each time, then ignore this part: > How is this possible? The only way we would get the marker is if we > either (a) listed the mappings by project_id, using > INSTANCE_MAPPING_MARKER as the query value, or (b) listed all the > mappings and somehow returned those to the user. > > I don't think (a) is a thing, and I'm not seeing how (b) could be > either. If you know of a place, please write a functional test for it > and we can get it resolves. In my proposed patch, I added a filter to > ensure that this doesn't show up in the get_by_cell_id() query, but > again, I'm not sure how this would ever be exposed to a user. > > https://review.openstack.org/#/c/567669/1/nova/objects/instance_mapping.py@173 As I said in my reply to gibi, I don't think making the user keep track of the marker is a very nice UX for a management CLI, nor is it as convenient for something like puppet to run as it has to parse the (grossly verbose) output each time to extract that marker. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev