Naming of Config keys

[Tim Penhey]

On 28/06/13 23:09, William Reade wrote:
> I think the consistency argument would be a lot stronger if we'd picked
> non-provider-specific names in the first place, but I don't think
> there's anything stopping us from taking a better approach with new
> providers. I'd be most in favour of "storage" and "shared-storage",
> myself, with a view to eventually deprecating the surprising variants
> that already exist (although I'm fine leaving them alone for now -- I
> think it's important to avoid excessive perturbation of the environment
> config code at the moment).
> 
> I think the practicality argument is very strong wrt "bucket" on clouds
> that don't have a "bucket" concept; but I'm not so sure it helps with a
> neutral name like "storage". Thoughts?

+1 on cloud neutral
+1 on "storage" and "shared storage"

> 
> On Thu, Jun 27, 2013 at 11:20 AM, Jeroen Vermeulen
> <jeroen.vermeulen at canonical.com <mailto:jeroen.vermeulen at canonical.com>>
> wrote:
> 
>     On 06/27/2013 04:14 AM, Julian Edwards wrote:
> 
>     > I like consistency, but "bucket" means far less to me than
>     > "container".  Therefore I don't see the problem in having
>     > provider-specific config names for similar concepts, since there's
>     > going to be  other config items totally unique to each one anyway.
> 
>     To assuage your conscience: I see it as a question of _which side_ of
>     the connection to be consistent with — Juju or the raw source of
>     machines.
> 
>     Big practical points for being consistent with the source of machines,
>     AFAIC.  We don't want our users to get stuck on "translation errors"
>     between their cloud's configuration nomenclature and Juju's.  Debugging
>     this kind of thing is hard enough even for those who know the source
>     code.
> 
> 
>     Jeroen
> 
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 
>