[DNM] ui build: split admin ui build based on license

[couchand]

This change plumbs the OSS/CCL build choice through to the admin UI build, to enable development of upcoming UI features covered by the CCL. CCL code is expected to be encapsulated by hook components, each of which will have a no-op version present in the OSS build.

I've also included a demonstration of how to implement a component under this system, but that is not intended to be merged. After people have taken a look at this, I'll move that information into documentation.

[cockroach-teamcity]

This change is 

[cuongdo]

What is the result when a user hits /ccl_only_admin_ui_link and they are using OSS build?

[benesch]

This approach LGTM provided everyone is comfortable with this method of CCL'ing. Nice work!

[benesch]

@cuongdo, we plan to stub out each top-level CCL component. So if you have an entire page under CCL, you'd presumably provide an OSS stub page that read "this page is only available in CCL binaries".

[cuongdo]

@benesch That sounds generally good. There should be some way of converting users to CCL builds, such as a link to https://www.cockroachlabs.com/product/cockroachdb-enterprise/

cc @dianasaur323 who will likely have better ideas

[couchand]

@cuongdo This change doesn't really get into routing (or specifics of how any fallback/alternative implementation would be handled). This mechanism is very general - the OSS build would implement a stub with the fallback behavior.

I've made suggestions on what would happen with the routing of the first CCL changes over on #19643. The implementation might be something like:

// ccl/src/whatever.tsx
export function addRoutes() {
  return <Route path="/whatever" component={Implementation} />;
}

// src/whatever.tsx
export function addRoutes() {
  return <Redirect path="/whatever" to="/fallback" />;
}

If we start to see common patterns we can refactor things later.

[bdarnell]

LGTM

---

Review status: 0 of 12 files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[couchand]

One significant requirement is not covered by this: handling clusters running the CCL build but without a valid license, which need to fall back to the OSS version of components.

[benesch]

which need to fall back to the OSS version of components.

At least some of them should display "enterprise license expired", no? You can just drop a if (license.isExpired()) return <LicenseExpired>; in the render method of each CCL entrypoint component. Somewhat inelegant, but equivalent to what we do on the Go side, and probably tractable as long as the number of CCL entrypoints is small.

[couchand]

There are two cases: one is an expired license, but another is someone who downloaded our compiled binaries but just wants to use the OSS features. It would be a little strange for them to see "license expired", or indeed anything related to enterprise licensing, in that case.

[benesch]

Agreed. You could check for both cases in the CCL entrypoints, though.

[couchand]

It just means we need to actually bundle the OSS versions, too, and allow the CCL components to reference the OSS ones. So I think we'll need to rethink the structure.

[benesch]

That should happen automatically if the CCL plugin looks like this:

if (!license.exists())
    return <OSSThingy>
else if (!license.valid())
    return <LicenseExpiredThingy>
else
    return <CCLThingy>

[couchand]

Yes, but how exactly do you import the OSS one from the CCL one? The configuration in this PR won't allow it, AFAICT.

[dianasaur323]

There is also the case when someone might want to downgrade from OSS after having an enterprise license that expired. This would be particularly true of people who signed up for a free 30-day trial license and decided not to convert. Would the user flow there be changing the cluster setting of the license field?

…

On Mon, Nov 13, 2017 at 1:59 PM, Andrew Couch ***@***.***> wrote: Yes, but how exactly do you import the OSS one from the CCL one? The configuration in this PR won't allow it, AFAICT. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19850 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFgDWFfE83Zjl7BUx7CDE9h-GHwjyVmAks5s2JGBgaJpZM4QT5eh> .

-- Diana Hsieh [email protected] 407-690-9048

[couchand]

Closing in favor of #20051