Open Stack

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 [isviridov at 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 <mbasnight at gmail.com<mailto:mbasnight at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131024/f94d2dfd/attachment.html>