Open Stack

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.

What do you think about it?


With best regards,
Ilya Sviridov

<http://www.mirantis.ru/>


On Tue, Oct 22, 2013 at 8:21 PM, Michael Basnight <mbasnight at gmail.com>wrote:

>
> On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote:
>
> > > 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.
> >
> > I agree for most users just selecting the datastore_type would be most
> intutive.
> >
> > 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?]
>
> im ok w/ making either "optional" if the criteria for selecting the
> _other_ is not ambiguous.
>
> _______________________________________________
> 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/20131023/0043340b/attachment.html>