user is able to create multiple workflows with same name under default namespace

[noa]

using mistral new RPMs
I am able to create the same workflow multiple time without supplying namespace,
on top of that once we have multiple workflows under default namespace in list, I am able to both execute and delete workflow by name.

this is an example of creating same workflow 3 times:

-bash-4.2# mistral workflow-create sanity_workflow.yaml
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:838: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/security.html
  InsecureRequestWarning)
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| ID | Name | Project ID | Tags | Input | Created at | Updated at |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| 58005745-e82a-42d2-84e1-0e0ce64d9329 | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:22:51 | None |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
-bash-4.2# mistral workflow-create sanity_workflow.yaml
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:838: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/security.html
  InsecureRequestWarning)
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| ID | Name | Project ID | Tags | Input | Created at | Updated at |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| 0120d06e-813f-4c43-ab22-429257779673 | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:23:04 | None |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
-bash-4.2# mistral workflow-create sanity_workflow.yaml
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:838: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/security.html
  InsecureRequestWarning)
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| ID | Name | Project ID | Tags | Input | Created at | Updated at |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
| c43fcbeb-4a9a-48c3-b828-615c6283203d | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:23:07 | None |
+--------------------------------------+------------------------+------------+--------+-------+---------------------+------------+
-bash-4.2# mistral workflow-list
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:838: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/security.html
  InsecureRequestWarning)
+--------------------------------------+------------------------+-------------------+--------+------------------------------+---------------------+------------+
| ID | Name | Project ID | Tags | Input | Created at | Updated at |
+--------------------------------------+------------------------+-------------------+--------+------------------------------+---------------------+------------+
| 72f0a374-c0ef-4da9-8b7f-41559a60f5ae | std.delete_instance | <default-project> | <none> | instance_id | 2017-09-26 06:20:59 | None |
| b0745125-7a53-4657-91f9-bb19e3e3ea30 | std.create_instance | <default-project> | <none> | name, image_id, flavor_id... | 2017-09-26 06:20:59 | None |
| 58005745-e82a-42d2-84e1-0e0ce64d9329 | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:22:51 | None |
| 0120d06e-813f-4c43-ab22-429257779673 | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:23:04 | None |
| c43fcbeb-4a9a-48c3-b828-615c6283203d | test_mistral_sanity_wf | None | <none> | | 2017-09-27 09:23:07 | None |
+--------------------------------------+------------------------+-------------------+--------+------------------------------+---------------------+------------+

[Dougal Matthews (d0ugal)]

I was unable to reproduce this bug.

(undercloud) [stack@493-heap--undercloud ~]$ cat wf.yaml
---
version: '2.0'

thing:
  tasks:
    noop:
      action: std.noop
(undercloud) [stack@493-heap--undercloud ~]$ mistral workflow-create wf.yaml
+--------------------------------------+-------+----------------------------------+--------+-------+---------------------+------------+
| ID | Name | Project ID | Tags | Input | Created at | Updated at |
+--------------------------------------+-------+----------------------------------+--------+-------+---------------------+------------+
| 2679845f-d42d-4cd1-be76-5708770640b2 | thing | a03a8bb14ae548f08558e15d158ffef4 | <none> | | 2017-10-11 08:57:19 | None |
+--------------------------------------+-------+----------------------------------+--------+-------+---------------------+------------+
(undercloud) [stack@493-heap--undercloud ~]$ mistral workflow-create wf.yaml
ERROR (app) Duplicate entry for WorkflowDefinition: ['name']

[Dougal Matthews (d0ugal)]

Can you please provide us with the exact Mistral version and/or Mistral rpm version?

[Renat Akhmerov (rakhmerov)]

I couldn't also reproduce it for the default namespace.

Noa, can you please run the following SQL on your database?

select scope, project_id, namespace from workflow_definitions_v2 where name = "test_mistral_sanity_wf";

and let us know what you have.

[Mike Fedosin (mfedosin)]

I reproduced it with keycloak auth

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/513372

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/513372
Committed: https://git.openstack.org/cgit/openstack/mistral/commit/?id=75e66117f049e00ba682f1d8977cdaa6eae35ef0
Submitter: Zuul
Branch: master

commit 75e66117f049e00ba682f1d8977cdaa6eae35ef0
Author: Mike Fedosin <email address hidden>
Date: Thu Oct 19 15:48:51 2017 +0300

    Invoke AuthHook before ContextHook

    Now in Mistral there is an AuthHook that should work for both Keystone
    and Keycloak. But for Keystone the real call to the server is performed
    earlier, in access_control [1], and AuthHook just contains a small check
    of X-Identity-Status header, that was injected before.

    Therefore, the sequence for Keystone auth is next:
    1. Call Keystone auth middleware during access control check and inject
       required headers in the request object.
    2. Call ContextHook and build the context.
    3. Call Keystone AuthHook and validate X-Identity-Status header we got
       on step 1. [2]

    Because of such a blurry logic, it seems that everything works as it
    should.
    But for Keycloak we honestly do autorization in AuthHook (where it
    supposed to be), and we have the following sequence of actions:

    1. Build an empty context without project_id and roles using ContextHook.
    2. Call AuthHook and perform the authorization. [3]

    So, even if the authorization was good and the headers were injected,
    the context had already been created.

    To fix this bug it's enough just to swap the order of calling the hooks,
    because this is logical to build user context after authorization
    process, because AuthHook may add new identity headers which can be
    requred for the context builder.

    [1] https://github.com/openstack/mistral/blob/master/mistral/api/access_control.py#L39
    [2] https://github.com/openstack/mistral/blob/master/mistral/auth/keystone.py#L33-L35
    [3] https://github.com/openstack/mistral/blob/master/mistral/auth/keycloak.py#L81

    Change-Id: I33ae6ddfe2a62851401305ff1dd8890b6937e842
    Closes-bug: #1719819

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/515011

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/515011
Committed: https://git.openstack.org/cgit/openstack/mistral/commit/?id=75baddd6522aa86bd9028258937709c828fa1404
Submitter: Zuul
Branch: stable/pike

commit 75baddd6522aa86bd9028258937709c828fa1404
Author: Mike Fedosin <email address hidden>
Date: Thu Oct 19 15:48:51 2017 +0300

    Invoke AuthHook before ContextHook

    Now in Mistral there is an AuthHook that should work for both Keystone
    and Keycloak. But for Keystone the real call to the server is performed
    earlier, in access_control [1], and AuthHook just contains a small check
    of X-Identity-Status header, that was injected before.

    Therefore, the sequence for Keystone auth is next:
    1. Call Keystone auth middleware during access control check and inject
       required headers in the request object.
    2. Call ContextHook and build the context.
    3. Call Keystone AuthHook and validate X-Identity-Status header we got
       on step 1. [2]

    Because of such a blurry logic, it seems that everything works as it
    should.
    But for Keycloak we honestly do autorization in AuthHook (where it
    supposed to be), and we have the following sequence of actions:

    1. Build an empty context without project_id and roles using ContextHook.
    2. Call AuthHook and perform the authorization. [3]

    So, even if the authorization was good and the headers were injected,
    the context had already been created.

    To fix this bug it's enough just to swap the order of calling the hooks,
    because this is logical to build user context after authorization
    process, because AuthHook may add new identity headers which can be
    requred for the context builder.

    [1] https://github.com/openstack/mistral/blob/master/mistral/api/access_control.py#L39
    [2] https://github.com/openstack/mistral/blob/master/mistral/auth/keystone.py#L33-L35
    [3] https://github.com/openstack/mistral/blob/master/mistral/auth/keycloak.py#L81

    Change-Id: I33ae6ddfe2a62851401305ff1dd8890b6937e842
    Closes-bug: #1719819
    (cherry picked from commit 75e66117f049e00ba682f1d8977cdaa6eae35ef0)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/mistral 5.2.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/mistral 6.0.0.0b2 development milestone.