<div dir="ltr">Have you looked at vendor data? It gives you a trusted way to inject arbitrary data into a config drive (or metadata server call), where that additional data isn't stored by nova and can be of an arbitrary size.<div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 9:07 AM Michael Johnson <<a href="mailto:johnsomor@gmail.com">johnsomor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The limited size of user_data (not even a floppy disk worth of space)<br>
is why Octavia has not used it either. We have used a, now deprecated,<br>
feature of config drive and nova.<br>
<br>
So, I am in full support of solving this problem.<br>
<br>
I would also like to request that we implement this in a way that we<br>
can secure the content. We use the config drive mechanism to load<br>
per-instance certificates and keys into the instance at boot time and<br>
would like to continue to use this mechanism to "seed" the instance.<br>
Our current mechanism stores the data along with the instance image,<br>
which means it is as protected as the OS image we boot.<br>
<br>
As we design the future, it would be awesome if we can provide the<br>
same or better level of protection for that content.<br>
<br>
Michael<br>
On Tue, Dec 4, 2018 at 7:34 AM Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
><br>
> On 12/04/2018 10:09 AM, Matt Riedemann wrote:<br>
> > On 12/4/2018 8:14 AM, Flavio Percoco wrote:<br>
> >> This is the current solution, which has allowed me to move forward<br>
> >> with the work I'm doing. Regardless, I would like us to discuss this.<br>
> >> I'd rather have the limit in Nova increased than adding a dependency<br>
> >> on another service that would, very likely, only be used for this<br>
> >> specific use case.<br>
> ><br>
> > As far as the DB limit, it's not just the actual instances.user_data<br>
> > table that matters [1] it's also the build_requests.instance column [2]<br>
> > and the latter is the bigger issue since it's an entire Instance object,<br>
> > including the user_data plus whatever else (like the flavor, metadata<br>
> > and system_metadata) serialized into that single MEDIUMTEXT field.<br>
> > That's what worries me about blowing up that field if we increase the<br>
> > API limit on user_data.<br>
><br>
> How prescient. :)<br>
><br>
> <a href="http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523.html</a><br>
><br>
> Best,<br>
> -jay<br>
><br>
<br>
</blockquote></div>