So if we decide to support any number of config options for each various datastore version, eventually we'll have large config files that will be hard to manage.
What about storing the extra config info for each datastore version in its own independent config file? So rather than having one increasingly bloated config file used by everything, you could optionally specify a file in the datastore_versions table of the database that would be looked up similar to how we load template files on demand. - Tim ________________________________ From: Ilya Sviridov [isviri...@mirantis.com] Sent: Thursday, October 24, 2013 7:40 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance So, we have 2 places for configuration management - database and config file Config file for tunning all datasource type behavior during installation and database for all changeable configurations during usage and administration of Trove installation. Database usecases: - update/custom image - update/custom packages - activating/deactivating datastore_type Config file usecases: - security group policy - provisioning mechanism - guest configuration parameters per database engine - provisioning parameters, templates - manager class ... In case if i need to register one more MySQL installation with following customization: - custom heat template - custom packages and additional monitoring tool package - open specific port for working with my monitoring tool on instance According to current concept should i add one more section in addition to existing mysql like below? [monitored_mysql] mount_point=/var/lib/mysql #8080 is port of my monitoring tool trove_security_group_rule_ports = 3306, 8080 heat_template=/etc/trove/heat_templates/monitored_mysql.yaml ... and put additional packages to database configuration? With best regards, Ilya Sviridov <http://www.mirantis.ru/> On Wed, Oct 23, 2013 at 9:37 PM, Michael Basnight <mbasni...@gmail.com<mailto:mbasni...@gmail.com>> wrote: On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote: > 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<http://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. Its fine for it to be in the config or the heat templates… im not sure it matters. what i would like to see is that specific thing to each service be in their own config group in the configuration. [mysql] mount_point=/var/lib/mysql … [redis] volume_support=False ….. and so on. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
