Open Stack

On 7/4/2016 8:45 AM, Matt Riedemann wrote:
> On 7/4/2016 3:40 AM, Daniel P. Berrange wrote:
>>
>> Won't the user provided files also get made available by the config
>> drive /
>> metadata service ?  I think that's the primary reason for file
>> injection not
>> being a fatal problem. Oh that and the fact that we've wanted to kill
>> it for
>> at least 3 years now :-)
>>
>> Regards,
>> Daniel
>>
>
> Ugh, good point, except force_config_drive defaults to False and running
> the metadata service is optional.
>
> In the case of this failing in the tempest-dsvm-neutron-full-ssh job,
> the instance is not created with a config drive, but the metadata
> service is running. Tempest doesn't check for the files there though
> because it's configured to expect file injection to work, so it ssh's
> into the guest and looks for the files.
>
> I have several changes up related to this:
>
> https://review.openstack.org/#/q/topic:bug/1598581
>
> One is making Tempest disable file injection tests by default since Nova
> disables file injection by default (at least for the libvirt driver).
>
> Another is changing devstack to actually configure nova/tempest for file
> injection which is what the job should have been doing anyway.
>
> My nova fix is not going to fly because of config drive (which I could
> check from the virt driver) and the metadata service (which I can't from
> the virt driver). So I guess the best we can do is log something...
>

I think I can still fail the server create from the libvirt driver if we 
can't honor the request.

For config drive, I can just check configdrive.required_by(instance) 
like we normally do.

For the metadata API, it's a bit uglier, but I could check if 'metadata' 
is in CONF.enabled_apis and if not, and no config drive and files were 
requested for injection but it's disabled, then we fail.

How terrible is that?

-- 

Thanks,

Matt Riedemann