Hi @AnalogJ I'd welcome a PR adding support for a LexiconProvider or alternatively you could include the octoDNS provider in Lexicon itself and allow people to get access to it by installing both libraries and configuring the class with lexicon.

octoDNS supports "advanced" record types and does A LOT of work beyond just interacting with the provider APIs to make disparate providers behave in a similar manner so it's not really something that octoDNS could just be switched to wholesale.

It would likely be super useful to have a LexiconProvider that easily allowed users to configure any of its supported providers, e.g.:

---
providers:
    ...

    godaddy:
        class: octodns.provider.lexicon.LexiconProvider
        provider: godaddy
        ...

/cc #28 which this is very similar to.

Hello! I took it upon myself to create such a provider. Whilst working I have gained a more throughout understanding of how Lexicon works and will update the PR shortly.

@AnalogJ I read here:
https://github.com/AnalogJ/lexicon/blob/master/SPECIFICATION.md

quoting the part about update:

Normal Behaviour Update a record. Record to be updated can be specified by providing id OR name, type and content

But for example in the powerdns _update method it looks like this ie identifier mandatory:

 def _update_record(self, identifier, rtype=None, name=None, content=None):
    self._delete_record(identifier)
    return self._create_record(rtype, name, content)

Furthermore the base class for all lexicon providers states the following:

    """
    Update a record. Identifier must be specified.
    """

This vexes me somewhat. It does seem like some providers makes the assumption that identifier is mandatory for certain operations, but the specification indicates it as an optional field (when listing records)

Now, my approach to this was just to parse whatever information I can from the various providers _list_records method and pass this on to the update / delete ones. The providers I have looked at seems to handle this and to me therefore this seems to be the best approach.

The problem though, is that the specification states either to provide identifier OR name, type and content. Also furthermore the powerdns provider relies on all fields be filled like in the example above.

I'm referring to this:

'id': string, // optional, provider specified unique id. Clients to treat this as opaque.

Would you mind shedding some light on this? Am I misinterpreting something, like is the id field not the same as the identifier field, although I see some providers treat it as such?

Now I have a PR which is tested both with gandi and namecheap lexicon providers.

There are some caveats, though: some Lexicon providers such like constellix cannot list more than one value for multi value records, not all providers support updating PTR, and others do not have unique identifiers for multi value records. The latter I have somewhat of a work around for in the pr, others I can't do much about in this provider. Suffice it to say that this provider should be used with caution.

Maybe it ought to warn when using a lexicon provider which is not tested or something. I don't know.

Based on all of the above I have mixed feelings about adding the provider. It seems like it'd always been a ymmv sort of thing given that it sounds like it only really supports the certbot usecase firmly and everything else is hit-or-miss. Maybe it'd make sense to release it as a stand-alone module, octodns_lexicon or something of that sort. If things go that route I'd be happy to link to it from the readme etc., but that'd give it enough room to document what does/doesn't work fully which wouldn't really fit into octoDNS's doc.

I put the third party library here: https://github.com/doddo/octodns-lexicon

I will also reject my PR.

I'll get a PR going soon-ish to add a section to the readme for related project that links there and will add my own external module https://github.com/ross/octodns-ddns while I'm at it.