Besides the strategy of selecting the default behavior. Let me share with you my ideas of configuration management in Trove and how the datastore concept can help with that.
Initially there was only one database and all configuration was in one config file. With adding of new databases, heat provisioning mechanism, we are introducing more options. Not only assigning specific image_id, but custom packages, heat templates, probably specific strategies of working with security groups. Such needs already exist because we have a lot of optional things in config, and any new feature is implemented with back sight to already existing legacy installations of Trove. What is actually datastore_type + datastore_version? The model which glues all the bricks together, so let us use it for all variable part of *service type* configuration. from current config file # Trove DNS trove_dns_support = False # Trove Security Groups for Instances trove_security_groups_support = True trove_security_groups_rules_support = False trove_security_group_rule_protocol = tcp trove_security_group_rule_port = 3306 trove_security_group_rule_cidr = 0.0.0.0/0 #guest_config = $pybasedir/etc/trove/trove-guestagent.conf.sample #cloudinit_location = /etc/trove/cloudinit block_device_mapping = vdb device_path = /dev/vdb mount_point = /var/lib/mysql All that configurations can be moved to data_strore (some defined in heat templates) and be manageable by operator in case if any default behavior should be changed. The trove-config becomes core functionality specific only. What do you think about it? With best regards, Ilya Sviridov <http://www.mirantis.ru/> On Tue, Oct 22, 2013 at 8:21 PM, Michael Basnight <mbasni...@gmail.com>wrote: > > On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote: > > > > It's not intuitive to the User, if they are specifying a version > alone. You don't boot a 'version' of something, with specifying what that > some thing is. I would rather they only specified the datastore_type > alone, and not have them specify a version at all. > > > > I agree for most users just selecting the datastore_type would be most > intutive. > > > > However, when they specify a version it's going to a be GUID which they > could only possibly know if they have recently enumerated all versions and > thus *know* the version is for the given type they want. In that case I > don't think most users would appreciate having to also pass the type- it > would just be redundant. So in that case why not make it optional?] > > im ok w/ making either "optional" if the criteria for selecting the > _other_ is not ambiguous. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev