cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koushik Das <koushik....@accelerite.com>
Subject Re: ConfigDepot vs the Config enum
Date Wed, 09 Nov 2016 06:56:41 GMT
There is no need for any DB script changes. When the MS starts up, it reads all the config
depot exposed by manager beans and update the DB appropriately.

-Koushik

On 07/11/16, 5:28 PM, "Jeff Hair" <jeff@greenqloud.com> wrote:

    Hi,
    
    That's what I thought was the case. Is there any particular process for
    moving configs to the depot besides just moving it out of the enum and into
    a manager bean somewhere? For example, would the pull request(s) need to
    have a database migration of some kind?
    
    Jeff
    
    *Jeff Hair*
    Technical Lead and Software Developer
    
    Tel: (+354) 415 0200
    jeff@greenqloud.com
    www.greenqloud.com
    
    On Mon, Nov 7, 2016 at 11:15 AM, Koushik Das <koushik.das@accelerite.com>
    wrote:
    
    > Config enum is legacy code. For any new configuration parameters
    > ConfigDepot should be used. Some of the parameters got moved from Config
    > enum to the appropriate manager classes (where it is getting used). But
    > there are still lot of them left to be moved. Feel free to submit a PR for
    > moving some of the config parameters to use ConfigDepot.
    >
    > -Koushik
    >
    > On 07/11/16, 4:31 PM, "Jeff Hair" <jeff@greenqloud.com> wrote:
    >
    >     Hi,
    >
    >     What's the difference between the Config enum and the ConfigDepot? It
    > seems
    >     like the configuration options are somwhat arbitrarily split between
    > the
    >     two. ConfigDepot entries get created automatically, while ones in the
    >     Config enum don't (and thus require a database migration). ConfigDepot
    >     items are defined on classes, while the Config enum is of course one
    > giant
    >     list.
    >
    >     Is there a plan to eventually use only one or the other? Or are they
    > going
    >     to be kept separate? Is there actually a use case for having both in
    > the
    >     codebase?
    >
    >     Jeff Hair
    >
    >
    >
    >
    >
    > DISCLAIMER
    > ==========
    > This e-mail may contain privileged and confidential information which is
    > the property of Accelerite, a Persistent Systems business. It is intended
    > only for the use of the individual or entity to which it is addressed. If
    > you are not the intended recipient, you are not authorized to read, retain,
    > copy, print, distribute or use this message. If you have received this
    > communication in error, please notify the sender and delete all copies of
    > this message. Accelerite, a Persistent Systems business does not accept any
    > liability for virus infected mails.
    >
    




DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Accelerite,
a Persistent Systems business. It is intended only for the use of the individual or entity
to which it is addressed. If you are not the intended recipient, you are not authorized to
read, retain, copy, print, distribute or use this message. If you have received this communication
in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent
Systems business does not accept any liability for virus infected mails.
Mime
View raw message