<div dir="ltr"><div><div>So, we have 2 places for configuration management - database and config file<br></div><br></div><div>Config file for tunning all datasource type behavior during installation and database for all changeable configurations during usage and administration of Trove installation.<br>
<br></div><div>Database usecases:<br></div><div>- update/custom image<br></div><div>- update/custom packages<br></div><div>- activating/deactivating datastore_type<br></div><div><br></div><div>Config file usecases:<br></div>
<div>- security group policy<br></div><div>- provisioning mechanism<br></div><div>- guest configuration parameters per database engine<br></div><div>- provisioning parameters, templates<br></div><div>- manager class<br></div>
<div>...<br><br></div><div>In case if i need to register one more MySQL installation with following customization:<br></div><div>- custom heat template<br></div><div></div><div>- custom packages and additional monitoring tool package<br>
</div><div>- open specific port for working with my monitoring tool on instance<br><br></div><div>According to current concept should i add one more section in addition to existing mysql like below?<br><br><span style="font-family:courier new,monospace">[monitored_mysql]<br>
mount_point=/var/lib/mysql<br></span></div><div><span style="font-family:courier new,monospace"><br>#8080 is port of my monitoring tool<br></span></div><div><span style="font-family:courier new,monospace">trove_security_group_rule_ports = </span><span style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">3306, </span>8080<br>
</span></div><div><span style="font-family:courier new,monospace">heat_template=/etc/trove/heat_templates/monitored_mysql.yaml<br></span></div><div><span style="font-family:courier new,monospace">...<br></span><br></div><div>
and put additional packages to database configuration?<br></div><div><br></div><div><br><br></div><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font color="#888888"><div><span style="color:rgb(0,0,0)">With best regards,<br>
Ilya Sviridov<br></span><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><br><a href="http://www.mirantis.ru/" style="color:rgb(0,0,204)" target="_blank"></a></span></div></font></div></div>
<br><br><div class="gmail_quote">On Wed, Oct 23, 2013 at 9:37 PM, Michael Basnight <span dir="ltr"><<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Oct 23, 2013, at 10:54 AM, Ilya Sviridov wrote:<br>
<br>
> Besides the strategy of selecting the default behavior.<br>
><br>
> Let me share with you my ideas of configuration management in Trove and how the datastore concept can help with that.<br>
><br>
> Initially there was only one database and all configuration was in one config file.<br>
> With adding of new databases, heat provisioning mechanism, we are introducing more options.<br>
><br>
> Not only assigning specific image_id, but custom packages, heat templates, probably specific strategies of working with security groups.<br>
> 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.<br>
><br>
> What is actually datastore_type + datastore_version?<br>
><br>
> The model which glues all the bricks together, so let us use it for all variable part of *service type* configuration.<br>
><br>
> from current config file<br>
><br>
> # Trove DNS<br>
> trove_dns_support = False<br>
><br>
> # Trove Security Groups for Instances<br>
> trove_security_groups_support = True<br>
> trove_security_groups_rules_support = False<br>
> trove_security_group_rule_protocol = tcp<br>
> trove_security_group_rule_port = 3306<br>
> trove_security_group_rule_cidr = <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
><br>
> #guest_config = $pybasedir/etc/trove/trove-guestagent.conf.sample<br>
> #cloudinit_location = /etc/trove/cloudinit<br>
><br>
> block_device_mapping = vdb<br>
> device_path = /dev/vdb<br>
> mount_point = /var/lib/mysql<br>
><br>
> 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.<br>
><br>
> The trove-config becomes core functionality specific only.<br>
<br>
</div></div>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.<br>
<br>
[mysql]<br>
mount_point=/var/lib/mysql<br>
…<br>
[redis]<br>
volume_support=False<br>
…..<br>
<br>
and so on.<br>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>