Open Stack

On 7/5/2016 4:36 PM, Matt Riedemann wrote:
> 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.

mtreinish pointed out that this would rely on having enabled_apis 
configured in nova.conf on the nova-compute nodes, which might not be 
the case, and I'm not sure we have a way to tell with oslo.config if an 
option is not present vs getting the default value when not specified. 
So I probably can't rely on that.

>
> How terrible is that?
>


-- 

Thanks,

Matt Riedemann