Composer fails to upload a blueprint which was imported from the manager
Description
To reproduce:
Upload a valid blueprint to the manager (I used the default example AWS-Basics-VM-Setup)
in the Local Blueprints page select the "Edit a copy in the Composer" option.
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
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:
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?
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.
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.
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?
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.
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.
Assignee
Reporter
Target Version
QA Owner
Premium Only
Documentation Required
Why Blocked?
Release Notes
Priority
Epic Link
Sprint
Priority
