Open Stack

I reported this bug separately and solved it:

https://code.launchpad.net/bugs/1122316

I didn't notice the thread issue you mentioned so there may be more to be done if you can get a repro case. I only noticed the issue on restarting nova-compute.

FYI the join you want if that is still necessary is:

joinedload_all('instances.system_metadata')

Vish

On Feb 8, 2013, at 10:01 AM, "Day, Phil" <philip.day at hp.com> wrote:

> Hi Folks,
>  
> I’ve been trying to track down the cause of this bug which is causing us a bit of grief at the moment:
>  
> https://bugs.launchpad.net/nova/+bug/1118608
>  
> There are two issues in here:
>  
> The first is a timing issue between a thread creating an instance and another request which comes back into the compute manager via the network manager to refresh the security group before the original thread has got to the point where it has populated the global “network_infos” structure inside the firewall driver.
>  
> I think I can fix this by adding a synchronisation lock to the incoming call, so it waits for any instance creation to finish.  I’ve posted this fix for review (open to other ideas on how to fix this)
>  
>  
> The second issue is further into this call  _get_instance_network_info in network/api.py is trying to extract the rxtx_factor value from the instance[‘instance_type’] – but the instance record doesn’t seem to have that information.
>  
> Looking at the db call that gets the instance data in the first place, db.security_group_get(), it doesn’t look as if it tries to do this join:
>  
> result = _security_group_get_query(context, session=session,
>                                        project_only=True).\
>                     filter_by(id=security_group_id).\
>                     options(joinedload_all('instances')).\
>                     first()
>  
> In my naivety I tried adding
>                  options(joinedload_all('instance_type')).\
>  
> to the query but to no effect.   
>  
> It doesn’t look like adding a call to conductor to get the instance_type data inside network/api  is the right way to go -  so can someone suggest another way to make this work ?
>  
>  
> (BTW it’s only the rxtx factor that is trying to be extracted from the instance_type – which based on a recent thread in here is only used in Xen at the moment.   Looking at the code its not obvious to me why this is even needed at this point).
>  
>  
> Thanks,
> Phil
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130211/ba63b662/attachment.html>