Re: [Monotone-devel] project status

[Stephen Leake]

Thomas Keller <address@hidden> writes:

>> Ok; does 'sync --key-to-push' via 'mtn automate stdio' do that?
>> Seems like it should, but I haven't tried it.
>
> How should it do that? I can only push keys from one database to
> another, but I want to put, i.e. store keys directly, similar to what
> `mtn read` provides. 

Eventually, the key will be back in the local database. So you might as
well add it to the local database first, then use --key-to-sync.

Is there anything wrong with that?

I'm still not clear why we are pushing a key to a server that hasn't
signed anything yet.

> Use case: Admin enters the ascii-amored version of a public key in a
> web form and hits "add". 

What is the larger use case; why does the key need to be on the server
but not in a local database first?

> The key is read and stored in the database via automate.

Why does it have to be via automate?

If the reason is "the web server does everything via automate", I guess
that's a good reason.

>> On the other hand, why does it have to be 'via a stdio connection'? 'mtn
>> sync --key-to-push mtn:server' should get the desired key into the
>> server's database.
>> 
>> Hmm. Maybe the server host rules don't allow a standard mtn: connection,
>> but require an ssh: connection. That makes sense. But that still means
>> 'mtn sync --key-to-push ssh:server' should work. 'automate' does not
>> need to be involved.
>
> It needs to be involved for the above use case.

You keep asserting this, but you haven't said why. The "add" button
could just as easily run a non-automate command.

>> There is also the race condition of deleting a key that is currently
>> being used to commit something; we'd need the keystore interface to
>> enforce a lock, and provide an atomic 'delete if unused' operation.
>> That's a big change for a minor use case.
>
> A more common race condition could be the usage of push and delete_key,
> but then again this should be rather rare as well timing-wise. But since
> both actions merely act on the database, shouldn't our transaction guard
> take care of this?

Only if the key interface enforces a transaction guard; I guess it
should already, since public keys are stored in the database. I was
thinking of the separate disk key store for private keys.

>> I gather the indefero server does not give shell access to a project
>> admin? That seems to be a bigger problem; I'm not sure we should be
>> putting project admin operations in the automate interface that are
>> already provided by a shell interface.
>
> indefero will have to manage "live" monotone databases behind usher.
> Shell access is not wanted for various reasons.

What reasons? That's what I don't understand. 

How many other operations that would normally be done by shell access
will need to be done via automate?

-- 
-- Stephe