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>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 > > > > #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 > 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
