Provide a "maintenance mode" state

[mssola]

There should be a "maintenance" mode for Portus. The idea is that once enabled, any subsequent pushes would be disallowed. This is a similar idea to something that has already been implemented on distribution's side, but since it's a configurable option there, an administrator would have to effectively restart the registry. In this case, we would disallow pushes without having to restart anything.

This raises other problems like: what happens if an admin sets maintenance mode on but there were some pushes already taking place ? This is something to be discussed in terms of how to best fix this.

[holgerreif]

An incomplete push is something that can happen anytime. It is in the responsibility of the client to recover from this error, and it is the responsibility of the regsitry admin to clean up any garbage arising from broken pushes. So there is nothing special about a broken push caused by a maintainance mode.

Since the current distribution's garbage collector works only with read-only registry, there is indeed a need for this maintainance mode.

One idea to make the transition to maintainance mode more smooth would be a grace period, where blob uploads are already prohibited, pushing of manifests and tags is still allowed. This would help for pushes nearly done, however I'm uncertain whether this would really change the picture...

[tboerger]

But if the push is already on the way, than the connection is already opened and permitted. Only new connections (pushes) will be denied, or do I miss something?

[holgerreif]

Well, there is a limited time the authentication token is valid. It's 5 mins bei default and is configurable (see #510).
Thus we cannot enforce the maintainance mode immediately. However we know, when the last token expires (since the token are not stored at portus AFAIK we can not iterate over all currently valid tokens. However we could store the time of last token issued so we know when the last token will expire.)
As an goodie, we can define a scheduled maintainance time in advance and issue only token that will not exceed this point in time.

@mssola: Do you think about two different maintainance modes: ro mode and complete offline mode?

[flavio]

However we know, when the last token expires (since the token are not stored at portus AFAIK we can iterate over all currently valid tokens.
Maybe we could store the time of last token issue so we know when the last token will expire.

This is a smart idea, I think it could work.

@mssola: Do you think about two different maintainance modes: ro mode and complete offline mode?

Personally I was envisioning just a read only mode

[mssola]

However we could store the time of last token issued so we know when the last token will expire.)
As an goodie, we can define a scheduled maintainance time in advance and issue only token that will not exceed this point in time.

👍

Do you think about two different maintainance modes: ro mode and complete offline mode?

I'm thinking in read only mode.

[holgerreif]

I'm thinking in read only mode.

Fine. BTW reading helps, in this case your initial comment:

once enabled, any subsequent pushes would be disallowed