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