[Fleet] fixing bug with preconfigured fleet server policy missing input

[juliaElastic]

Came across a bug during testing preconfigured policies. When creating a preconfigured agent policy with package policy, the policy inputs were not reflected in .fleet-policies index until some other action was done that updated the policy.
The reason is that the agent policy's revision was not bumped after creating the package policy and assigning it to the agent policy.

Steps to reproduce:

• add the following preconfig to kibana.dev.yml:

xpack.fleet.agents.enabled: true
xpack.fleet.packages:
    - name: fleet_server
      version: latest
xpack.fleet.agentPolicies:
    - name: Fleet Server policy
      id: fleet-server-policy
      description: Fleet server policy
      namespace: default
      package_policies:
          - name: Fleet Server
            package:
                name: fleet_server

• start es and kibana
• check that the agent policy was created with fleet server integration
• Bug: check the content of .fleet-policies index: the inputs array is empty:

{
            "id" : "fleet-server-policy",
            "outputs" : {
              "default" : {
                "type" : "elasticsearch",
                "hosts" : [
                  "http://localhost:9200"
                ]
              }
            },
            "inputs" : [],
}

• Expected after the fix: the inputs array should be populated:

"inputs" : [
              {
                "id" : "0f0c8c65-2ab8-5ec0-b653-09b26e6ab549",
                "revision" : 1,
                "name" : "Fleet Server",
                "type" : "fleet-server",
                "data_stream" : {
                  "namespace" : "default"
                },
                "use_output" : "default",
                "server" : {
                  "port" : 8220,
                  "host" : "0.0.0.0"
                },
                "meta" : {
                  "package" : {
                    "name" : "fleet_server",
                    "version" : "1.1.1"
                  }
                }
              }
            ],
            "revision" : 2,

This bug also had a side effect that when trying to enroll fleet server to this preconfigured policy, it got stuck at some point due to the missing inputs.

docker run --add-host host.docker.internal:host-gateway -e FLEET_SERVER_ENABLE=true -e KIBANA_HOST=http://host.docker.internal:5601/julia -e FLEET_SERVER_ELASTICSEARCH_HOST=http://host.docker.internal:9200 -e KIBANA_USERNAME=elastic -e KIBANA_PASSWORD=changeme -e FLEET_SERVER_POLICY_ID=fleet-server-policy -p 8220:8220 -e FLEET_SERVER_INSECURE_HTTP=1 -e KIBANA_FLEET_SETUP=1  -e ELASTICSEARCH_USERNAME=elastic -e ELASTICSEARCH_PASSWORD=changeme --rm docker.elastic.co/beats/elastic-agent:8.1.0-SNAPSHOT

Requesting service_token from Kibana.
Created service_token named: token-1643812150550
Performing setup of Fleet in Kibana

Policy selected for enrollment:  fleet-server-policy
...
{"log.level":"info","@timestamp":"2022-02-02T14:29:18.949Z","log.origin":{"file.name":"cmd/enroll_cmd.go","file.line":777},"message":"Fleet Server - Waiting on fleet-server input to be added to policy: fleet-server-policy","ecs.version":"1.6.0"}

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

this is the bumpRevision flag, which was previously set to false on create (and true on update), it is used here:
So the agent policy has to be version bumped after creating and assigning the new package policy.

kibana/x-pack/plugins/fleet/server/services/package_policy.ts

Lines 177 to 204 in b8c1323

	const newSo = await soClient.create<PackagePolicySOAttributes>(
	SAVED_OBJECT_TYPE,
	{
	...packagePolicy,
	inputs,
	elasticsearch,
	revision: 1,
	created_at: isoDate,
	created_by: options?.user?.username ?? 'system',
	updated_at: isoDate,
	updated_by: options?.user?.username ?? 'system',
	},
	{ ...options, id: packagePolicyId }
	);
	// Assign it to the given agent policy
	await agentPolicyService.assignPackagePolicies(
	soClient,
	esClient,
	packagePolicy.policy_id,
	[newSo.id],
	{
	user: options?.user,
	bumpRevision: options?.bumpRevision ?? true,
	force: options?.force,
	}
	);

[nchaulet]

Should we backport to 8.0 and 7.17 ? I think we should

[nchaulet]

🚀

[juliaElastic]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 2974070
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

✅ unchanged

History

• 💔 Build #21373 failed bab3747

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @juliaElastic

[kibanamachine]

💔 Some backports could not be created

Status	Branch	Result
✅	8.0
❌	8.2	The branch "8.2" is invalid or doesn't exist
❌	7.17	Backport failed because of merge conflicts

How to fix

Re-run the backport manually:

node scripts/backport --pr 124363

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

[juliaElastic]

Should we backport to 8.0 and 7.17 ? I think we should

@nchaulet I found that the change introducing the bumpAgentPolicyRevision is not backported to 7.17, so I'll skip that backport here as well.

[dikshachauhan-qasource]

Hi @juliaElastic

We have validated merges related to PR on 8.0 BC1 build at Cloud and on-prem env both.

• We are able to fetch Input related properties related to fleet server policy.

Screenshot on Cloud:

Screenshot on on-prem env:

Please let us know if more validations are required to be performed under manual side on this ticket.

Thanks
QAS