Open Stack

On 12/4/2018 8:14 AM, Flavio Percoco wrote:
> This is the current solution, which has allowed me to move forward
> with the work I'm doing. Regardless, I would like us to discuss this.
> I'd rather have the limit in Nova increased than adding a dependency
> on another service that would, very likely, only be used for this
> specific use case.

As far as the DB limit, it's not just the actual instances.user_data 
table that matters [1] it's also the build_requests.instance column [2] 
and the latter is the bigger issue since it's an entire Instance object, 
including the user_data plus whatever else (like the flavor, metadata 
and system_metadata) serialized into that single MEDIUMTEXT field. 
That's what worries me about blowing up that field if we increase the 
API limit on user_data.

As for passing a handle to a thing in another service, we have talked a 
few times about integrating with a service like Glare to allow users to 
pass a baremetal node RAID config handle when creating a server and then 
nova would pull the spec down from Glare and pass it on to the virt 
driver. We could do the same thing here I would think. Glare is just a 
generic artifact repository right? I think that would be a better 
long-term solution for these problems rather than trying to make nova a 
blob store.

[1] 
https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/db/sqlalchemy/models.py#L288
[2] 
https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/db/sqlalchemy/api_models.py#L250

-- 

Thanks,

Matt