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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
