<div dir="ltr">Just to throw a deployment perspective into the hat...<div style>One of the things we're working on is starting to validate deployment recipes early in the OS development process, by using direct pull of openstack source from github (rather than wait for packages to be fully backed).</div>
<div style><br></div><div style>The idea is that we'd seed the deployment of release N+1 with the know to be working deployment of release N. Once deployed, run tempest tests, and see what breaks. This is not meant to replace reviewer's insisting on backcomapt configs, just to catch the cases reviews missed a breaking change, or one was intentionally admitted (see below).</div>
<div style><br></div><div style>Right now we're going through this exercise against grizzly, based on folsom recipes. One early find is the keystone PKI/UUID default change, which required some handling.</div><div style>
Right now this capability (which we call pull-from-source) is not quite fully stable, but we hope that for Havana we can consider including this as a non-voting gate comment into gerrit.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 1:26 PM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Wed, Feb 6, 2013 at 9:22 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nova (and most other OpenStack components) have an ever increasing<br>
number of configuration parameters which accept classnames.<br>
Obviously, we're doing this to make it possible to plug in custom<br>
implementations of various interfaces, which is great.<br>
<br>
There are two downsides to this<br>
<br>
- The user has to know about obscure, often undocumented, python<br>
module names.<br>
<br></blockquote><div><br></div></div><div>Thanks for shining a light on this particular difficulty. While we now have a sample nova.conf with descriptions, any use of and changes to class names in both nova and quantum have caused headaches for users. And doc bugs too. <br>
</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Any time we rename a class, or refactor code possibly deleting<br>
or merging classes, we break the end config file upon upgrade.<br>
<br>
The first point is a mere usability matter, but the second point<br>
is a serious deployment issue IMHO, which can only get worse as<br>
usage of OpenStack increases & people expect more stability and<br>
consistency across upgrades.<br>
<br>
Historically code changes have been pretty fast & loose config<br>
parameters, arbitrarily changing them at any time for any reason.<br>
AFAIK there are no formal rules defined about changing config<br>
paramaters, but in some of the recent changes I've submitted<br>
which involved config changes, reviewers wanted backwards compat<br>
to be maintained. The result that when renaming, or obsoleting<br>
existing classses we're having to keep around stubs for the old<br>
classes to avoid breaking user config files. This is not a good<br>
approach for long term maintainability of the codebase.<br>
<br>
IMHO the core issue here is that by using classnames in config<br>
parameters we are exposing what we (developers) generally consider<br>
to be internal/private implementation details to the end user. End<br>
user expectations wrt upgrades are thus restricting what we can do<br>
with our internal implementations.<br>
<br>
I don't think it is acceptable to have a situation where configuration<br>
file parameters restrict what we can do in terms of re-arranging /<br>
refactoring our codebase. Provided we maintain the same featureset<br>
compatibility, we should be free todo any code refactoring we desire.<br>
<br>
The only way we can do this is if we do *NOT* require the use of<br>
classnames in config parameters. Instead we should treat all these<br>
config parameters as being more like enumerations, and map those to<br>
classnames internally<br></blockquote><div><br></div></div></div><div>I would completely support this and wish I had dev resources to put behind the effort. Is there a group who wants to work on this? <br><br></div><div>
44 isn't bad out of over 600 I might add.<br>
</div><div><br></div><div>Let me help any way I can.<span class="HOEnZb"><font color="#888888"><br><br>Anne<br></font></span></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
eg for the compute_driver instead of having the user set<br>
<br>
compute_driver=nova.virt.libvirt.LibvirtDriver<br>
<br>
they would do<br>
<br>
compute_driver=libvirt<br>
<br>
and internally nova would resolve this to the classname. Obviously the<br>
key issue is how we deal with the mapping of enum values to classnames.<br>
If we just had a table of mappings in the codebase, then it ceases to<br>
be possible for people to drop in custom out-of-tree implementations<br>
from 3rd parties.<br>
<br>
One option to this would be to allow the config parameters to take a<br>
enum value, or a classname. We would declare the enum values as<br>
"stable, guaranteed upgrade compatibility", and the use of classnames<br>
as "liable to break on upgrade". The intent would be that all our<br>
documentation / tools like devstack, etc would use the short enum<br>
names by default. The only people who would ever use classnames for the<br>
config parameters, would be those who need to plug in a 3rd party impl<br>
that is not part of the main openstack codebase.<br>
<br>
A different option would be to only ever allow for enum values in the<br>
config parameter, but define a way for 3rd parties to register their<br>
new impls. For example, you could have them do something like<br>
<br>
# cd /usr/share/openstack/nova/configmap/compute_driver<br>
# echo "nova.virt.libvirt.LibvirtDriver" > libvirt<br>
<br>
as a way to register that the 'compute_driver' parameter gets a new<br>
valid option of 'libvirt' mapping to the classname<br>
"nova.virt.libvirt.LibvirtDriver"<br>
<br>
Regards,<br>
Daniel<br>
<br>
[1] In fact Nova currently has at least 44 classname based options<br>
<br>
$ grep 'nova\.' etc/nova/nova.conf.sample | grep -v "# " | sort | sed -e 's/#//'<br>
allowed_rpc_exception_modules=nova.openstack.common.exception,nova.exception,cinder.exception,exceptions<br>
cert_manager=nova.cert.manager.CertManager<br>
compute_api_class=nova.compute.api.API<br>
compute_manager=nova.compute.manager.ComputeManager<br>
compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler<br>
compute_stats_class=nova.compute.stats.Stats<br>
consoleauth_manager=nova.consoleauth.manager.ConsoleAuthManager<br>
console_driver=nova.console.xvp.XVPConsoleProxy<br>
console_manager=nova.console.manager.ConsoleProxyManager<br>
db_driver=nova.db<br>
default_scheduler_driver=nova.scheduler.chance.ChanceScheduler<br>
driver=nova.cells.rpc_driver.CellsRPCDriver<br>
driver=nova.virt.baremetal.pxe.PXE<br>
floating_ip_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver<br>
instance_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver<br>
l3_lib=nova.network.l3.LinuxNetL3<br>
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtBridgeDriver<br>
libvirt_volume_drivers=iscsi=nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver,local=nova.virt.libvirt.volume.LibvirtVolumeDriver,fake=nova.virt.libvirt.volume.LibvirtFakeVolumeDriver,rbd=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,sheepdog=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,nfs=nova.virt.libvirt.volume_nfs.NfsVolumeDriver<br>
linuxnet_interface_driver=nova.network.linux_net.LinuxBridgeInterfaceDriver<br>
manager=nova.cells.manager.CellsManager<br>
manager=nova.conductor.manager.ConductorManager<br>
metadata_manager=nova.api.manager.MetadataManager<br>
monkey_patch_modules=nova.api.ec2.cloud:nova.notifier.api.notify_decorator,nova.compute.api:nova.notifier.api.notify_decorator<br>
network_api_class=nova.network.api.API<br>
network_driver=nova.network.linux_net<br>
network_manager=nova.network.manager.VlanManager<br>
osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions<br>
power_manager=nova.virt.baremetal.ipmi.IPMI<br>
quota_driver=nova.quota.DbQuotaDriver<br>
rpc_backend=nova.openstack.common.rpc.impl_kombu<br>
rpc_zmq_matchmaker=nova.openstack.common.rpc.matchmaker.MatchMakerLocalhost<br>
scheduler_available_filters=nova.scheduler.filters.all_filters<br>
scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler<br>
scheduler_host_manager=nova.scheduler.host_manager.HostManager<br>
scheduler_manager=nova.scheduler.manager.SchedulerManager<br>
scheduler=nova.cells.scheduler.CellsScheduler<br>
scheduler_weight_classes=nova.scheduler.weights.all_weighers<br>
security_group_api=nova.compute.api.SecurityGroupAPI<br>
security_group_handler=nova.network.sg.NullSecurityGroupHandler<br>
sqlite_db=nova.sqlite<br>
vif_driver=nova.virt.baremetal.vif_driver.BareMetalVIFDriver<br>
volume_api_class=nova.volume.cinder.API<br>
volume_driver=nova.virt.baremetal.volume_driver.LibvirtVolumeDriver<br>
xenapi_vif_driver=nova.virt.xenapi.vif.XenAPIBridgeDriver<br>
<span><font color="#888888"><br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>