Open Stack

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>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 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/96cac6b5/attachment.html>