License plan check on namespaces

Addresses #2019

• Create helper methods for checking feature availability for namespaces
• Put 'File locks' and 'Deploy board' under namespace license check
• Allow checking features by using symbols instead plain long strings (e.g. :file_lock, :deploy_board)
• Add namespace API for admin usage

changed milestone to %9.2

added ~481018 license labels

changed the description

approved this merge request

mentioned in issue #2466 (closed)

The only failure (https://gitlab.com/gitlab-org/gitlab-ee/builds/16910063) will be fixed by https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1949 (it's broken on master)

canceled the automatic merge

merged

mentioned in commit bb2a0453

@oswaldo It looks as though there isn't a way to select a default "blank" entry from the Plan dropdown:

I think we could solve this by adding:

{ include_blank: 'No Associated Plan' }

to:

= f.select :plan, options_for_select(Namespace::EE_PLANS.keys.map { |plan| [plan.titleize, plan] }, f.object.plan), {}, class: 'form-control'

and doing something with the validator to translate an empty string into a nil value.

Thanks @mikegreiling, would you mind doing this as a follow-up on the FE improvements for license ?

@oswaldo I tried playing around with it, but I'm not sure I know enough about ActiveSupport to get this to work. I've added the change above, but it still returns an error when I submit the form without selecting a plan.

I see you used allow_nil in the validator:

validates :plan, inclusion: { in: EE_PLANS.keys }, allow_nil: true

but the include_blank option in the form field doesn't seem to translate to nil when the form is validated. can you help me with this?

@DouweM shouldn't this be %9.3, not %9.2?

@mikegreiling Right.

changed milestone to %9.3

mentioned in issue #2482 (closed)

@oswaldo since this MR is closed, I've opened a new issue here: #2482 (closed)

Thanks for trying this @mikegreiling, I've answered on https://gitlab.com/gitlab-org/gitlab-ee/issues/2482#note_30626456.

mentioned in merge request !1993 (merged)

mentioned in merge request !1942 (merged)

@DouweM Just double-checking. Are we able to get this on Pick into Stable for %9.4 correct? Otherwise, we'll have issues with new features with this check that are already merged into master! e.g. https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2091

Also, we'll need a new license to GitLab.com with a premium plan.

changed milestone to %9.4

@oswaldo it's fine, this is in 9.4 anyway

I was pinged in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609 about reviewing some related changes and noticed that namespaces.plan is a string. This is a really bad idea for a number of reasons (see https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609/diffs#f48d33fd8319861c4aa5178bddc85c0f9e3a0f06_0_20).

Why was this not discussed with any DB specialists or brought up in the #database channel? We've been trying hard to get rid of these kind of schema choices, so it's a bit frustrating to see them being introduced again.

Copying my comments here in case the diff goes away:

Also why are we storing the plan name as a string? That's horribly inefficient since we'll be repeating the same text values over and over and over again. There should be a plans table and a namespaces.plan_id column pointing to it.

---

I realise this plans setup probably predates this MR, but it's a really bad setup and I'm surprised no DB specialists were consulted when this setup was decided upon.

---

To clarify, let's say we end up with 5 million users. That's 5 million times early_adopter, which is 13 bytes plus at least 1 byte for the encoding. This leads us to wasting at least 66 MB for just a bunch of plan names. Sure, it's only 66 MB but it's still a complete waste when we could instead use integers, which would only take 38 MB. Depending on the table structure (in terms of padding between columns) we may end up wasting even more by using strings.

Also imagine wanting to update a plan name at some point. By storing these as string values per namespace we'd have to update every single occurrence, whereas using a plans table means only having to update 1 row. It gets even worse when we want to re-use these plan names elsewhere.

The solution which is much better is to simply have a plans table with 3 columns (in this order):

• created_at
• id
• name

Then for namespaces you'd add a plan_id column with a foreign key (probably set to ON DELETE NULLIFY so that removing a plan won't remove namespaces).

This would allow us to do everything we want, without wasting the space or making it harder to update/remove plan names.

mentioned in merge request !2609 (merged)

Thanks for clarifying and checking this in. https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1961#note_36841523 and https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1961#note_36841573 makes a lot of sense. Glad we're working on https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2609!

mentioned in commit 550f9a74

mentioned in commit d9114c15

mentioned in commit 47608924