Open Stack

On 12/18/2018 6:48 AM, Jay Pipes wrote:
> Well, technically, we *could* do all three of the above, right? :) It's 
> not an either/or situation, AFAIU.

True.

> 
>  From looking at your patches, I think the long-term solution to this 
> would be to stop storing the instance password in the 
> instance_system_metadata table, but from looking into those code paths 
> (eww...) I realize that would be a huge chunk of tech debt refactoring. 
> Maybe something to line up for early Train?

I would think we'd do an online data migration on access of a new 
Instance.password field. When building new instances or setting the 
instance password via the API, we'd set that field rather than in 
instance.system_metadata. When accessing the Instance.password field, if 
it's not set, we'd lazy-load and pop it from system_metadata, set it on 
the Instance.password field and save() that change. That's the model we 
have used for migrating things like instance.flavor and instance.keypairs.

We'd still be stuck with my patch to the metadata API that conditionally 
joins system_metadata if vendordata_providers are configured, so anyone 
using those probably doesn't get the performance benefit anyway.

It's hard to assess the benefit of prioritizing work on any of this 
without more operators coming forward and saying, "yes this is 
definitely a specific pain for us running the metadata-api", especially 
since the pre-loading of metadata/system_metadata in the API happened 
back in Mitaka.

-- 

Thanks,

Matt