[Openstack] [openstack][nova] Changes-Since parameter in Nova API not working as expected

Jay Pipes jaypipes at gmail.com
Mon Jun 26 17:25:26 UTC 2017


On 06/26/2017 12:58 PM, Jose Renato Santos wrote:
> Hi
> 
> I am accessing the nova api using the gophercloud SDK 
> https://github.com/rackspace/gophercloud
> 
> I am running Openstack Newton installed with Openstack Ansible
> 
> I am accessing the “List Servers” call of the nova Api with the 
> Changes-Since parameters for efficient polling
> 
> https://developer.openstack.org/api-guide/compute/polling_changes-since_parameter.html
> 
> However, the API is not working as I expected.
> 
> When I stop or start a server instance, the API successfully detects the 
> change in the server state and returns the server in the next call to 
> ListServers with the Changes-Since parameter, as expected.
> 
> But when I attach a new security group to the server, the API does not 
> detect any change in the state of the server and does not return the 
> server in the next call  to ListServers with the Changes-Since parameter.
> 
> I would expect that changing the list of security groups attached to a 
> server would be considered a change in the server state and reported 
> when using the Changes-Since parameter, but that is not the behavior 
> that I am seeing.
> 
> Can someone please let me know if this is a known bug?

Changes to an instance's security group rules are not considered when 
listing servers by updated_at field value. This is mostly because the 
security group [rules] are Neutron objects and are not one-to-one 
associated with a Nova instance.

I'm not sure it's a bug per-se, but I suppose we could entertain a 
feature request to set the updated_at timestamp column for all instances 
associated with a security group when that security group's rules are 
changed.

But that would probably open up a can of worms that Nova developers may 
not be willing to deal with. For instance, should we update the 
instances.update_at table every time a volume is changed? a network port 
that an instance is associated with? A heat stack that launched the 
volume? etc etc.

Best,
-jay



More information about the Openstack mailing list