<div dir="ltr"><div><div>Besides the strategy of selecting the default behavior.<br><br></div><div>Let me share with you my ideas of configuration management in Trove and how the datastore concept can help with that.<br><br>
</div><div>Initially there was only one database and all configuration was in one config file. <br></div><div>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>
</div><div>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.</div><div><br></div>What is actually datastore_type + datastore_version?<br>
<br></div><div>The model which glues all the bricks together, so let us use it for all variable part of *service type* configuration.<br></div><div><br></div><div>from current config file<br><span style="font-family:courier new,monospace"><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">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</span><br><br></div><div>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>
</div><div></div><div></div><div><br></div><div></div><div>The trove-config becomes core functionality specific only.<br><br></div><div>What do you think about it?<br></div><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 Tue, Oct 22, 2013 at 8:21 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="im"><br>
On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote:<br>
<br>
> > It's not intuitive to the User, if they are specifying a version alone. You don't boot a 'version' of something, with specifying what that some thing is. I would rather they only specified the datastore_type alone, and not have them specify a version at all.<br>
><br>
> I agree for most users just selecting the datastore_type would be most intutive.<br>
><br>
</div>> However, when they specify a version it's going to a be GUID which they could only possibly know if they have recently enumerated all versions and thus *know* the version is for the given type they want. In that case I don't think most users would appreciate having to also pass the type- it would just be redundant. So in that case why not make it optional?]<br>
<br>
im ok w/ making either "optional" if the criteria for selecting the _other_ is not ambiguous.<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></div>