cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hair <j...@greenqloud.com>
Subject Re: ConfigDepot vs the Config enum
Date Mon, 07 Nov 2016 11:58:16 GMT
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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message