Naming of Config keys

[William Reade]

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?


On Thu, Jun 27, 2013 at 11:20 AM, Jeroen Vermeulen <
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
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130628/1558591f/attachment.html>