Composer fails to upload a blueprint which was imported from the manager

Description

To reproduce:

  1. Upload a valid blueprint to the manager (I used the default example AWS-Basics-VM-Setup)

  2. in the Local Blueprints page select the "Edit a copy in the Composer" option.

  3. After the blueprint is opened in the composer try to upload it to the manager. The upload will fail, claiming that the blueprint is not valid.

This is part of the main flow of the Composer functionality. we need to resolve this for 5.1

Activity

Show:
Jakub Niezgoda
August 11, 2020, 2:06 PM

Found the reason for the problem. tenant header was not set in PUT /blueprints/validate/validate request from Composer backend. For blueprints without plugins defined as imports using plugin:<name> syntax it was OK, but when it comes to checking if plugin is installed on the manager it failed.

Created preliminary fix:

Before moving forward (adding test cases) I’ve got two questions:

  1. We validate blueprint in two cases: 1. Validate action, 2. Upload to Manager action. Right now I’m always using default_tenant for Validate action and I’m using tenant selected by the user in the modal for Upload to Manager action. Let me know if that’s fine. Maybe we should introduce a modal window on Validate action click and ask for the tenant that blueprint should be validated on?

  2. Response for PUT /blueprints/validate/validate request takes very long time IMO. Even for simple blueprint like (without nodes, just simple two imports):

    it takes sometimes even 1 minute. Is that the same problem as with ? , do you think it is related? If not, then I will create another issue about it.

Jakub Niezgoda
August 14, 2020, 12:15 PM

As I’ll be off for 3 working days I’ve merged my current solution. Please take a look at my previous comment - p.1 about tenant.

I will keep that issue In Progress as I want to implement first full Stage-Composer integration test.

Ofer Yarom
August 16, 2020, 10:38 AM


Regarding #1 - Yes, I believe it will make a lot of sense to validate the blueprint in the context of a tenant. will the API that you use support that? do we need a backend change?

Regarding #2 - I suspect this relates to an issue that mentioned with regards to slow blueprint upload when AWS plugin is imported. is it? also, do we have a ticket for that?

Jakub Niezgoda
August 20, 2020, 8:48 AM

Regarding #1 - Yes, I believe it will make a lot of sense to validate the blueprint in the context of a tenant. will the API that you use support that? do we need a backend change?

Yes, API supports that, backend is already expecting tenant to be set in the request header. Right now (with the latest fix) I’m using always “default_tenant” for validation. We can improve it. Either we can have modal window asking on which tenant user wants to validate (showing up after clicking Validate icon) or we can have some Composer-wide dropdown somewhere on the screen to select tenant user is working on.

Ofer Yarom
August 20, 2020, 8:55 AM

Yes, API supports that, backend is already expecting tenant to be set in the request header. Right now (with the latest fix) I’m using always “default_tenant” for validation. We can improve it. Either we can have modal window asking on which tenant user wants to validate (showing up after clicking Validate icon) or we can have some Composer-wide dropdown somewhere on the screen to select tenant user is working on.

I think the modal approach is better. it will reduce user errors.

Done

Assignee

Jakub Niezgoda

Reporter

Ofer Yarom

Labels

Target Version

5.1

QA Owner

None

Premium Only

yes

Documentation Required

No

Why Blocked?

None

Release Notes

yes

Priority

None

Epic Link

Sprint

None

Priority

Unprioritized
Configure