I am 10000% behind that idea. It makes things easier to manage.
On Thu, Oct 24, 2013 at 10:44 AM, Tim Simpson <tim.simp...@rackspace.com>wrote: > 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>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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev