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/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b5... [2] https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b5... -- Thanks, Matt