On 03/10/2014 11:49 AM, Petr Spacek wrote:
> On 7.3.2014 17:33, Dmitri Pal wrote:
>> I do not think it is the right architectural approach to try to fix a 
>> specific
>> use case with one off solution while we already know that we need a key 
>> storage.
>> I would rather do things right and reusable than jam them into the currently
>> proposed release boundaries.
> I want to make clear that I'm not opposed to Vault in general. I'm questioning
> the necessity of Vault from the beginning because it will delay DNSSEC
> significantly.

+1, I also now see number of scenarios where Vault will be needed.

> 
> One of the proposals in this thread is to use something simple for DNSSEC keys
> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is
> available and stable enough (in some later release).
> 
>> I understand that Vault brings a lot of work to the table. But let us do it
>> right and if it does not fit into 4.0 let us do it in 4.1.
> We will have one huge release with DNSSEC + Vault at once if we to postpone
> DNSSEC to the same release as Vault.
> 
> As a result, it would be harder to debug it because we will have to find if
> something is broken because of:
> - DNSSEC-IPA integration
> - Vault-IPA integration
> - DNSSEC-Vault integration.
> 
> I don't think it is a good idea to make such huge release.
> 
> "Release early, release often"
> 

I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC
without Vault does not cost us too much time and it would seem that the Vault
is not going to squeeze in 4.0 deadlines, I would rather release the poor man's
solution in 4.0 and switch to Vault when it's available in 4.1.

This would let our users test the non-Vault parts of our DNSSEC solution
instead of waiting to test a perfect solution.

Martin

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to