Open Stack

I am 10000% behind that idea.  It makes things easier to manage.


On Thu, Oct 24, 2013 at 10:44 AM, Tim Simpson <tim.simpson at rackspace.com>wrote:

>  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>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
>>
>>
>
> _______________________________________________
> 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/7b5064c3/attachment.html>