Re: [Openstack-operators] [nova] Fail build request if we can't inject files?
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... -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Fail build request if we can't inject files?
On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote: > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it runs > ssh validation + neutron + config drive + metadata service, which will test > the virtual device tagging 2.32 microversion API (added last week). > > The job has a file injection test that fails consistently which is keeping > it from being voting. > > After debugging, the problem is the files to inject are silently ignored > because n-cpu is configured with libvirt.inject_partition=-2 by default. > That disables file injection: > > https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030 > > We don't even log a warning if the user requested files to inject and we > can't honor it. If I were a user and tried to inject files when creating a > server but they didn't show up in the guest, I'd open a support ticket > against my cloud provider. So I don't think a warning (that only the admin > sees) is sufficient here. This isn't something that's discoverable from the > API either, it's really host configuration / capability (something we still > need to tackle). 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 -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
