DatabaseRelationAdaptor incorrectly sets accessor properties while the interface implements functions with parameters

[David Ames]

Charms.openstack's DatabaseRelationAdapter incorrectly sets accessor properties that the actual interface implements as functions with paramaters.

charms.openstack:
class DatabaseRelationAdapter(OpenStackRelationAdapter):
    """
    Adapter for the Database relation interface.
    """

    interface_type = "database"

    def __init__(self, relation):
        add_accessors = ['password', 'username', 'database']

Interface:
    def password(self, prefix=None):
        """
        Return a database password.
        """
        if prefix:
            return self.get_remote(prefix + '_password')
        return self.get_remote('password')

This bug has likely been around since the beginning of OpenStack reactive charms as most charms use the get_uri adaptor for their database access.

Required Action:

Check templates for any direct access to password, username or database
Remove the add_accessors line of charms.openstack's DatabaseRelationAdapter
Determine if get_username and get_database adaptors are required or if the interface can be used directly while passing prefix as a parameter
Refactor as necessary

[Alex Kavanagh (ajkavanagh)]

So the prefix problem is interesting, because we have to be able to access them in templates from a single adapter. The prefix needs to be optional. Thus, my idea is, that we want to access (in a template) a no-prefix item as:

    adapter.password

But, it would be cool to access a prefixed item with:

    adapter.prefix.nova_cell0.password

How could we do this?

There's a couple of ways. We could just return a dictionary of dictionaries from a prefix property, and let Jinga2 do it's automatic attribute/key __getitem__() magic to do the lookups, but that's fairly nasty from other code.

The 2nd way would be to return an object from a prefix property that has a __getattribute__ method hack to accept the prefix and then provide a object that has the autoaccessor properties on it locked to the prefix. i.e. take the autoaccessor properties off of the adapter.

Obviously, the former is easier, but less satisfying; the latter requires a little more work in the DatabaseRelationAdapter class to provide a nice ergonomic API