Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Platform and Legacy platform servers integration #39047

Merged
merged 12 commits into from
Jun 19, 2019

Conversation

mshustov
Copy link
Contributor

@mshustov mshustov commented Jun 16, 2019

Summary

Security integration into New platform has several pain points related to running authc/authz and sharing their results to both New & Legacy platform servers. This PR removes a concept of 2 different servers, instead:

  • The New platform creates hapi server
  • The New platform passes created server to the Legacy platform, which extends it accordingly
  • The New platform runs listening on a port.

Advantages

  • simple architecture. we can get rid of LegacyPlatformProxy
  • simple API integration, because we use the same server, the request objects, etc. can get rid of IncomingMessage
  • Security plugin migration is not a blocker for other plugin migration anymore. All New Platform routes are protected by implementation in the Legacy platform.
  • Security handles only the one server, no needs to think how to proxy results to another HTTP server instance, how to share route declarations (auth: false/true}
  • we can postpone refactoring several places that use Security directly dashboard_mode, setup x-pack headers

Disadvantages

  • Legacy platform mutates and extends server instance in the wild. that could affect New platform in an unpredictable way. The new platform doesn't expose low-level details like hapi to the plugins, perhaps my fears are exaggerated.
  • It's hard to reason about what pieces already migrated to New platform

Both points can be solved via decorating hapi extension points(server.ext, server.expose) to track its usage in the Legacy platform and log deprecation warnings.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@elasticmachine
Copy link
Contributor

💔 Build Failed

Required to use a common security interceptor for incoming http requests
@mshustov mshustov force-pushed the new-legacy-server-integration branch from fa343d4 to 52bfa2d Compare June 16, 2019 14:09
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov added Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes review Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.3.0 labels Jun 17, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@mshustov mshustov marked this pull request as ready for review June 17, 2019 11:14
@mshustov mshustov requested a review from a team as a code owner June 17, 2019 11:14
@mshustov mshustov requested a review from epixa June 17, 2019 11:14
@mshustov mshustov changed the title [WIP] New Platform and Legacy platform servers integration New Platform and Legacy platform servers integration Jun 17, 2019
@mshustov mshustov requested a review from azasypkin June 17, 2019 11:41
@epixa
Copy link
Contributor

epixa commented Jun 17, 2019

One problem this introduces is in upgrading hapi. The existing setup allowed us to upgrade hapi in the new platform independently of the old platform, which is helpful because the new platform has much better test coverage around http, so we can rely more heavily on our tests to flag issues. We took advantage of this when doing our hapi 14 -> 17 upgrade.

I'm not necessarily against this change if it's a pragmatic way forward and unblocks migration, but I think moving all of the authc/authz stuff over to the new platform is still crucial in the short term even with this change in place. We have to dramatically scale back the scope of http related features that are being used in the legacy platform otherwise we're looking at another multi-month long effort to upgrade hapi, which just distracts us from new platform work anyway.

Copy link
Contributor

@epixa epixa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The http proxy stuff is non-intuitive, so at the very least I'm happy that will go.

One general piece of feedback for future PRs: try to limit variable renaming and such when it isn't a necessary byproduct of your change. There were a lot of variable renames to add the "mock" prefix to things in tests in this PR that made it harder to review.

src/core/server/http/http_service.test.ts Outdated Show resolved Hide resolved
src/core/server/http/http_service.test.ts Outdated Show resolved Hide resolved
src/core/server/index.ts Outdated Show resolved Hide resolved
src/core/server/legacy/legacy_service.ts Show resolved Hide resolved
@mshustov mshustov force-pushed the new-legacy-server-integration branch from e089a18 to a033248 Compare June 17, 2019 15:12
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@azasypkin azasypkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, glad we managed to get rid of "proxifier"! Just one concern that I think we should address before we merge this.

src/core/server/legacy/legacy_service.ts Show resolved Hide resolved
@@ -102,14 +99,26 @@ export class HttpService implements CoreService<HttpServiceSetup, HttpServiceSta
}

return {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: do we consume this return value anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the core doesn't use it anymore. @toddself are you going to use isListening somewhere?

@elasticmachine
Copy link
Contributor

💔 Build Failed

@joshdover
Copy link
Contributor

I don't have any immediate concerns. I took a look at the mutating code we do have in the legacy world and haven't found anything too egregious. It helps that none of these mutations will be exposed to the NP plugins directly.

In terms of Hapi upgrade-ability, this will make it harder. Though, taking a look at Hapi release notes for the most recent major (v18), I don't see anything new or improved that would necessarily be something we need. The new features introduced would probably be something we implement in the NP's abstractions anyways (if we even wanted them in the first place). The breaking changes in v18 also don't appear as nearly as bad as v17 was.

@restrry's point above that the implementations are coupled already is a good argument for needing to do them both at the same time anyways (at least with the current design).

If we move forward with this, the Security plugin still plans to move to the NP in the near-term, correct? I think it's important that gets completed and fleshed out sooner than later. We need to be sure there's not any glaring holes in our HTTP service design now rather than late in the 7.x lifecycle.

Haven't taken a deep dive into the code just yet (will do today though).

@kobelb
Copy link
Contributor

kobelb commented Jun 18, 2019

If we move forward with this, the Security plugin still plans to move to the NP in the near-term, correct?

Regardless of the decision here, we'll be moving forward with the NP migration for authc/authz.

@@ -156,7 +154,8 @@ export class HttpServer {

await this.server.start();
const serverPath = this.config!.rewriteBasePath || this.config!.basePath || '';
this.log.debug(`http server running at ${this.server.info.uri}${serverPath}`);
this.log.info(`http server running`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary template string. Also, can you elaborate why this log needs to change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to log with info level something similar to Server running from the Legacy platform. I decided to use http server running, also re-phrase this one to highlight the difference between them.

src/core/server/http/http_service.test.ts Outdated Show resolved Hide resolved
src/core/server/http/http_service.ts Outdated Show resolved Hide resolved
src/core/server/http/http_service.ts Show resolved Hide resolved
src/core/server/http/http_service.ts Show resolved Hide resolved
root = kbnTestServer.createRoot();
}, 30000);

afterEach(async () => await root.shutdown());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be shortened to:

afterEach(() => root.shutdown());

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@joshdover joshdover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be noted that requests to NP endpoints will now be logged by the request logger (@elastic/good plugin) in the legacy system (when --logging.verbose=true). This is technically a behavior change, but we don't have any NP endpoints yet, so 🤷‍♂ .

NP requests are not currently logged by the NP logger, so there aren't duplicates, but we should migrate request logging to NP.

src/core/server/http/http_server.ts Outdated Show resolved Hide resolved
src/core/server/http/http_service.ts Show resolved Hide resolved
src/core/server/http/http_service.ts Show resolved Hide resolved
src/core/server/http/http_service.ts Show resolved Hide resolved
@mshustov
Copy link
Contributor Author

mshustov commented Jun 19, 2019

NP requests are not currently logged by the NP logger, so there aren't duplicates, but we should migrate request logging to NP.

yes, I will create an issue. there are other small pieces that we can start migrating to NP - logging, all hapi lifecycle events

updated #39330

@mshustov mshustov force-pushed the new-legacy-server-integration branch from a62ed69 to aaabf88 Compare June 19, 2019 04:03
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov merged commit a75d777 into elastic:master Jun 19, 2019
@mshustov mshustov deleted the new-legacy-server-integration branch June 19, 2019 14:32
mshustov added a commit to mshustov/kibana that referenced this pull request Jun 19, 2019
* New and Legacy platforms share http server instance.

Required to use a common security interceptor for incoming http requests

* generate docs

* remove excessive contract method

* add test for New platform compatibility

* address comments part #1

* log server running only for http server

* fix test. mutate hapi request headers for BWC with legacy

* return 503 on start

* address @eli comments

* address @joshdover comments
mshustov added a commit that referenced this pull request Jun 19, 2019
* New and Legacy platforms share http server instance.

Required to use a common security interceptor for incoming http requests

* generate docs

* remove excessive contract method

* add test for New platform compatibility

* address comments part #1

* log server running only for http server

* fix test. mutate hapi request headers for BWC with legacy

* return 503 on start

* address @eli comments

* address @joshdover comments
dgieselaar pushed a commit to dgieselaar/kibana that referenced this pull request Jun 21, 2019
* New and Legacy platforms share http server instance.

Required to use a common security interceptor for incoming http requests

* generate docs

* remove excessive contract method

* add test for New platform compatibility

* address comments part #1

* log server running only for http server

* fix test. mutate hapi request headers for BWC with legacy

* return 503 on start

* address @eli comments

* address @joshdover comments
@mshustov mshustov removed the review label Jun 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.3.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants