Open Stack

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.

Michael

On Wed, Dec 5, 2018 at 9:07 AM Michael Johnson <johnsomor at gmail.com> wrote:

> 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 at 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.html
> >
> > Best,
> > -jay
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181205/283a552f/attachment.html>