Forbid duplicated rlimits with same type

[hqhq]

Alternative of #583 , as what we do for namespaces
in #597 .

Signed-off-by: Qiang Huang [email protected]

[wking]

On Wed, Nov 02, 2016 at 07:15:57PM -0700, Qiang Huang wrote:

Alternative of #583 , as what we do for namespaces
in #597 .

The concern with using objects for namespaces was the path handling
[1](and I still think it would have been better to use an object
there [2]). But we require at least one limit for rlimit entries
(otherwise what's the point?), so I don't see a reason to not go
with an object for rlimits.

[wking]

On Wed, Nov 02, 2016 at 08:36:27PM -0700, W. Trevor King wrote:

But we require at least one limit for rlimit entries (otherwise
what's the point?)…

Actually, we don't. But an rlimit entry with neither hard nor soft is
a no-op, while in #598 we needed to distinguish between no-op and
“create a new namespace”. So I think my initial “so I don't see a
reason to not go with an object for rlimits” still stands.

[hqhq]

@wking I still don't see the problem of using array here after we fix the duplicated type issue.

[wking]

It's nothing insurmountable, but add-or-replace and removal are much easier with objects. In #597 I linked to this hoop jumping you need to support then for arrays.

[crosbymichael]

LGTM

[dqminh]

LGTM

[mrunalp]

LGTM