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

Observability AI Assistant Tests Deployment Agnostic #205194

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

arturoliduena
Copy link
Contributor

@arturoliduena arturoliduena commented Dec 27, 2024

Closes #192718

Summary

This PR add a deployment-agnostic testing environment for Observability AI Assistant tests by unifying the duplicated tests for stateful and serverless environments. It create the ObservabilityAIAssistantApiClient to work seamlessly in both environments, enabling a single test to run across stateful, CI, and MKI.

Initial efforts focus on deduplicating the conversations.spec.ts and connectors.spec.ts files, as these already run in all environments.

Move / dedup the tests that exist in stateful and serverless. They run in serverless CI but not MKI and add the skipMki tag.
chat.spec.ts
complete.spec.ts
elasticsearch.spec.ts
public_complete.spec.ts
alerts.spec.ts

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

  • 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
  • Unit or functional tests were updated or added to match the most common scenarios
  • If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
  • This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
  • Flaky Test Runner was used on any tests changed
  • The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

@arturoliduena arturoliduena added release_note:skip Skip the PR/issue when compiling release notes Team:Obs AI Assistant Observability AI Assistant v8.18.0 labels Dec 27, 2024
@arturoliduena arturoliduena requested a review from a team as a code owner December 27, 2024 11:29
@elasticmachine
Copy link
Contributor

Pinging @elastic/obs-ai-assistant (Team:Obs AI Assistant)

@arturoliduena arturoliduena requested a review from a team as a code owner December 27, 2024 12:05
@botelastic botelastic bot added the ci:project-deploy-observability Create an Observability project label Dec 27, 2024
Copy link
Contributor

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)


it('Returns a 2xx for enterprise license', async () => {
const { status } = await observabilityAIAssistantAPIClient.editor({
endpoint: `GET ${CONNECTOR_API_URL}`,
Copy link
Member

@sorenlouv sorenlouv Jan 2, 2025

Choose a reason for hiding this comment

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

nit: I suggest not using variables here. It's harder to read and search for. Also, I'm not sure the typescript intellisense for parameters and typed responses works when using variables

Suggested change
endpoint: `GET ${CONNECTOR_API_URL}`,
endpoint: `GET /internal/observability_ai_assistant/connectors`,

Copy link
Member

Choose a reason for hiding this comment

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

If you really want to make it DRY I suggest adding a helper and re-use that instead:

const getConnectors = () =>
  observabilityAIAssistantAPIClient.editor({
    endpoint: `GET /internal/observability_ai_assistant/connectors`,
  });

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree. Now that I’m moving many of these tests, I won’t use a variable and will ensure they follow a consistent pattern since we currently have a mix.

}
}

async function createProxyActionConnector({
Copy link
Member

Choose a reason for hiding this comment

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

Should we have a shared helper for creating the proxy action connector? It's already defined at least 3 times:

export async function createProxyActionConnector({

export async function createConnector(proxy: LlmProxy, supertest: SuperTestAgent) {

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 will keep only one, I will get rid of the duplicate functions.

Comment on lines 119 to 121
await observabilityAIAssistantAPIClient
.slsEditor({
try {
await observabilityAIAssistantAPIClient.editor({
Copy link
Member

Choose a reason for hiding this comment

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

Feels good getting rid of the serverless-specific client. Is the plan to get rid of x-pack/test_serverless/api_integration/test_suites/observability/ai_assistant/common/observability_ai_assistant_api_client.ts entirely?

Copy link
Contributor

Choose a reason for hiding this comment

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

We can remove it entirely if we get all the tests running in deployment agnostic, unless there is some case where we want a serverless only test because of some serverless only feature. Probably wouldn't hurt to leave it.

@@ -46,212 +46,6 @@ export default function ApiTest({ getService }: FtrProviderContext) {
});

describe('Conversations', () => {
describe('without conversations', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

This whole file should be safe to move over to deployment agnostic and not exist in stateful tests. I'm assuming you decided not to move it was because of the security roles and access privileges test suite which doesn't exist in serverless, but it soon will: #205210

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exactly. I only moved the common tests between stateful and serverless. I’ll move the security roles and access privaleges to deployment-agnostic and remove it from stateful and serverless.

@@ -8,13 +8,11 @@
import expect from '@kbn/expect';
import type { Agent as SuperTestAgent } from 'supertest';
Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -1264,7 +1264,7 @@ packages/kbn-monaco/src/esql @elastic/kibana-esql
/x-pack/test/observability_ai_assistant_functional @elastic/obs-ai-assistant
/x-pack/test_serverless/**/test_suites/observability/ai_assistant @elastic/obs-ai-assistant
/x-pack/test/functional/es_archives/observability/ai_assistant @elastic/obs-ai-assistant

/x-pack/test/api_integration/deployment_agnostic/apis/observability/ai_assistant @elastic/obs-ai-assistant
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't look related to your change but Github complains about errors in this file

image

Copy link
Member

Choose a reason for hiding this comment

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

It's valid on main which is odd

image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing that out, @sorenlouv. I checked, and the file is now valid in this branch as well. It might have been a temporary issue or something resolved during recent changes(I did a rebase recently).

Copy link
Member

@sorenlouv sorenlouv left a comment

Choose a reason for hiding this comment

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

Just one comment about CODEOWNERS file

@arturoliduena arturoliduena force-pushed the obs-ai-assistant-192718-deployment-agnostic-api-integration-tests branch from c1c4339 to 1dc1987 Compare January 3, 2025 20:38
@arturoliduena arturoliduena added the backport:skip This commit does not require backporting label Jan 4, 2025
@@ -201,6 +201,7 @@ export function ObservabilityAIAssistantApiProvider(context: DeploymentAgnosticF
admin: observabilityAIAssistantApiClient.makeInternalApiRequest('admin'),
viewer: observabilityAIAssistantApiClient.makeInternalApiRequest('viewer'),
editor: observabilityAIAssistantApiClient.makeInternalApiRequest('editor'),
unauthorizedUser: observabilityAIAssistantApiClient.makeInternalApiRequest('viewer'),
Copy link
Member

@sorenlouv sorenlouv Jan 6, 2025

Choose a reason for hiding this comment

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

Can't we simply use the existing viewer? Also, what do you expect to happen if unauthorizedUser is used to call an endpoint that viewer is allowed to access?

Copy link
Contributor

@viduni94 viduni94 Jan 6, 2025

Choose a reason for hiding this comment

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

Hey @arturoliduena
You might not be able to use the viewer role for unauthorizedUser in this manner for DA tests. It was done for serverless this way, because we force the user to be unauthorized by not passing the cookie header.

https://github.com/elastic/kibana/pull/205210/files#diff-febc7c89d3de714505db725fb9c264974eea6a5b29542b8782ebb0bab98a92d7R219

However, since the cookie is always included in makeInternalApiRequest, this user will be a viewer with authorization.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey @sorenlouv and @viduni94,
We can simulate an unauthorized user by omitting credentials entirely with a function like makeInternalApiRequestWithoutCredentials:

  function makeInternalApiRequest(role: string) {
    return async <TEndpoint extends InternalEndpoint<APIEndpoint>>(
      options: Options<TEndpoint>
    ): Promise<SupertestReturnType<TEndpoint>> => {
      const headers: Record<string, string> = {
        ...samlAuth.getInternalRequestHeader(),
        ...(await samlAuth.getM2MApiCookieCredentialsWithRoleScope(role)),
      };

      return makeApiRequest({
        options,
        headers,
      });
    };
  }

  function makeInternalApiRequestWithoutCredentials() {
    return async <TEndpoint extends InternalEndpoint<APIEndpoint>>(
      options: Options<TEndpoint>
    ): Promise<SupertestReturnType<TEndpoint>> => {
      const headers: Record<string, string> = {
        ...samlAuth.getInternalRequestHeader(),
      };

      return makeApiRequest({
        options,
        headers,
      });
    };
  }

However, the problem with this approach is that omitting credentials will result in a 401 Unauthorized response instead of a 403 Forbidden. This doesn’t align with the intention of the test, which is to verify whether a user with insufficient permissions can access specific endpoints (DELETE, POST, PUT).

To properly simulate this, the user needs to be authenticated (avoiding 401 Unauthorized) but lack the necessary permissions, resulting in a 403 Forbidden. This is why I think it makes sense to use the viewer role here.

I agree with Søren that adding an additional unauthorizedUser role like this:

unauthorizedUser: observabilityAIAssistantApiClient.makeInternalApiRequest('viewer')

is unnecessary. Instead, we can simply use the existing viewer role:

viewer: observabilityAIAssistantApiClient.makeInternalApiRequest('viewer')

This keeps the implementation clean and ensures that we’re testing for insufficient permissions correctly. Let me know if you agree

Copy link
Member

@sorenlouv sorenlouv Jan 7, 2025

Choose a reason for hiding this comment

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

If I read that correctly, you'll authenticate as the viewer user. That sounds good to me.

Copy link
Contributor

@viduni94 viduni94 Jan 7, 2025

Choose a reason for hiding this comment

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

What I meant is not to have a user without credentials, but to have a user with a role that has insufficient privileges to access the AI Assistant APIs.

If the viewer role fits that criteria, I'm good with this.

Copy link
Member

Choose a reason for hiding this comment

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

It just seems odd to have a user called unauthorizedUser. Because even with just the viewer role there are APIs they are authorised to access.


type PublicEndpoint<T extends APIEndpoint> = T extends `${string} /api/${string}` ? T : never;

function createObservabilityAIAssistantApiClient({
Copy link
Member

@sorenlouv sorenlouv Jan 7, 2025

Choose a reason for hiding this comment

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

@elasticmachine
Copy link
Contributor

elasticmachine commented Jan 7, 2025

💚 Build Succeeded

  • Buildkite Build
  • Commit: b80b0ee
  • Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-205194-b80b0ee2b0a6

Metrics [docs]

✅ unchanged

History

describe('/internal/observability_ai_assistant/chat', () => {
describe('/internal/observability_ai_assistant/chat', function () {
// TODO: https://github.com/elastic/kibana/issues/192751
this.tags(['skipMKI']);
Copy link
Contributor

Choose a reason for hiding this comment

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

We can be replace skipMKI with failsOnMKI if we want to be more descriptive that we aren't wanting to skip but that its failing so we have to skip.

viduni94 added a commit that referenced this pull request Jan 8, 2025
…s test suite (#205631)

Closes #205537

## Summary

The knowledge base migration test suite is missing in serverless. This
PR adds it to the serverless test suite.
- This has a dependancy to #205194
since we are removing all serverless tests and adding them to DA tests.
- If the DA tests PR gets merged first, I'll refactor this PR to add it
there.

### Checklist

- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
kibanamachine pushed a commit to kibanamachine/kibana that referenced this pull request Jan 8, 2025
…s test suite (elastic#205631)

Closes elastic#205537

## Summary

The knowledge base migration test suite is missing in serverless. This
PR adds it to the serverless test suite.
- This has a dependancy to elastic#205194
since we are removing all serverless tests and adding them to DA tests.
- If the DA tests PR gets merged first, I'll refactor this PR to add it
there.

### Checklist

- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

(cherry picked from commit e32ff8e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting ci:project-deploy-observability Create an Observability project release_note:skip Skip the PR/issue when compiling release notes Team:Obs AI Assistant Observability AI Assistant v8.18.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Obs AI Assistant] Deployment agnostic API integration tests
5 participants