-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
New Platform and Legacy platform servers integration #39047
Conversation
💔 Build Failed |
Required to use a common security interceptor for incoming http requests
fa343d4
to
52bfa2d
Compare
💚 Build Succeeded |
💚 Build Succeeded |
💚 Build Succeeded |
Pinging @elastic/kibana-platform |
Pinging @elastic/kibana-security |
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 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. |
There was a problem hiding this 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.
e089a18
to
a033248
Compare
💚 Build Succeeded |
There was a problem hiding this 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.
@@ -102,14 +99,26 @@ export class HttpService implements CoreService<HttpServiceSetup, HttpServiceSta | |||
} | |||
|
|||
return { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
packages/kbn-test/src/functional_tests/lib/run_kibana_server.js
Outdated
Show resolved
Hide resolved
💔 Build Failed |
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). |
Regardless of the decision here, we'll be moving forward with the NP migration for authc/authz. |
src/core/server/http/http_server.ts
Outdated
@@ -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`); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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/legacy/integration_tests/legacy_service.test.ts
Outdated
Show resolved
Hide resolved
root = kbnTestServer.createRoot(); | ||
}, 30000); | ||
|
||
afterEach(async () => await root.shutdown()); |
There was a problem hiding this comment.
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());
src/core/server/legacy/integration_tests/legacy_service.test.ts
Outdated
Show resolved
Hide resolved
src/core/server/legacy/integration_tests/legacy_service.test.ts
Outdated
Show resolved
Hide resolved
src/core/server/legacy/integration_tests/legacy_service.test.ts
Outdated
Show resolved
Hide resolved
💔 Build Failed |
There was a problem hiding this 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.
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 |
a62ed69
to
aaabf88
Compare
💚 Build Succeeded |
* 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
* 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
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:hapi
serverAdvantages
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
}Disadvantages
server instance
in the wild. that could affect New platform in an unpredictable way. The new platform doesn't expose low-level details likehapi
to the plugins, perhaps my fears are exaggerated.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
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers