The limited size of user_data (not even a floppy disk worth of space) is why Octavia has not used it either. We have used a, now deprecated, feature of config drive and nova. So, I am in full support of solving this problem. I would also like to request that we implement this in a way that we can secure the content. We use the config drive mechanism to load per-instance certificates and keys into the instance at boot time and would like to continue to use this mechanism to "seed" the instance. Our current mechanism stores the data along with the instance image, which means it is as protected as the OS image we boot. As we design the future, it would be awesome if we can provide the same or better level of protection for that content. Michael On Tue, Dec 4, 2018 at 7:34 AM Jay Pipes <jaypipes@gmail.com> wrote:
On 12/04/2018 10:09 AM, Matt Riedemann wrote:
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.
How prescient. :)
http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523....
Best, -jay