[Openstack] [Mistral] : Rest API POST v2/execution body
Hi All,
I have a VM running mistral api server at port 8989 on it. I was trying out
the API's. I was able to do
Request :
[GET] 192.168.56.103:8989/v2/executions
Response :
{
"executions": [
{
"state_info": null,
"created_at": "2017-04-17 08:34:39",
"description": "",
"state": "SUCCESS",
"workflow_name": "my_workflow",
"task_execution_id": null,
"updated_at": "2017-04-17 08:34:40",
"workflow_id": "8104b38b-a493-4b75-b6c5-02f7d7cbe3ba",
"params": "{}",
"input": "{\"names\": [\"John\", \"Mistral\", \"Ivan\",
\"Crystal\"]}",
"id": "ecec10fe-3b7c-4d45-b83d-3f5d9f25fe93"
},
{
"state_info": null,
"created_at": "2017-04-17 08:40:12",
"description": "",
"state": "SUCCESS",
"workflow_name": "my_workflow",
"task_execution_id": null,
"updated_at": "2017-04-17 08:40:14",
"workflow_id": "8104b38b-a493-4b75-b6c5-02f7d7cbe3ba",
"params": "{}",
"input": "{\"names\": [\"John\", \"Mistral\", \"Ivan\",
\"Crystal\"]}",
"id": "d01db85d-d627-4a84-b006-a138ec29f207"
},
{
"state_info": null,
"created_at": "2017-05-29 08:35:04",
"description": "",
"state": "SUCCESS",
"workflow_name": "my_workflow",
"task_execution_id": null,
"updated_at": "2017-05-29 08:35:07",
"workflow_id": "8104b38b-a493-4b75-b6c5-02f7d7cbe3ba",
"params": "{}",
"input": "{\"names\": [\"John\", \"Mistral\", \"Ivan\",
\"Crystal\"]}",
"id": "389247d6-c9be-40b7-a19b-0c47adaffbc6"
}
]
}
Now, I wanted to do [POST] 192.168.56.103:8989/v2/executions.
I don't know what wf_ex parameter is. Can someone suggest me with the
sample POST body for the above API?
Cheers,
Sameer
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] restrict access for users between domains
You have to make changes to the policy.json. I had to debug and create new roles etc on my env since the admin for the project x can only manage domain x and not been able to see anything else. Remo Inviato da iPhone > Il giorno 29 mag 2017, alle ore 08:09, Volodymyr Litovka ha > scritto: > > Hi friends, > > is there way to define domain's admin and restrict this person to access only > his domain? > > At the moment (Ocata release), if I : > - create domain by 'openstack domain create devtest > - create user in the domain by 'openstack user create udevtest --domain > devtest --password xx > - create project in the domain by 'openstack project create devmin --domain > devtest > - assign role 'admin' to the user on both the domain and the project: > * openstack role add admin --user udevtest --domain devtest > * openstack role add admin --project-domain devtest --project devmin --user > udevtest > > then, using user's 'udevtest' credentials: > > OS_REGION_NAME=RegionOne > OS_DEFAULT_DOMAIN=devtest > OS_USER_DOMAIN_NAME=devtest > OS_PROJECT_DOMAIN_NAME=devtest > OS_PROJECT_NAME=devmin > OS_USERNAME=udevtest > OS_PASSWORD=x > > OS_AUTH_STRATEGY=keystone > OS_IDENTITY_API_VERSION=3 > OS_AUTH_URL=http://controller:5000/v3 > OS_INTERFACE=internal > > I'm able to get a list of all users and projects in 'default' domain and even > more - add / delete users and projects in 'default' domain. > > In fact, user 'udevtest' has nothing to domain 'default', but assigned global > role 'admin' - probably, that is the problem, because policy.json's rule > 'admin_required' is just check for 'role:admin', which is true. On the other > hand, if I create role 'admin' specific to domain 'devtest' and assign it to > user on both domain and project in the domain, then I get error "User > f1c1cd3438c24255a2baa85f326dfc40 (which is udevtest) has no access to project > 1dbbaf2fb0bc4d5da270e48d4a92bc62 (which is devmin)", so seems local roles > doesn't matter. > > Is the only way (I hope it's legacy way :-) ) to change policy.json (as some > pages on Internet were suggesting) or I'm doing something wrong? > > Thank you! > > -- > Volodymyr Litovka > "Vision without Execution is Hallucination." -- Thomas Edison > !DSPAM:1,592c3c0850931589493451! > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > !DSPAM:1,592c3c0850931589493451! ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] restrict access for users between domains
Hi friends, is there way to define domain's admin and restrict this person to access only his domain? At the moment (Ocata release), if I : - create domain by '_openstack domain create devtest_ - create user in the domain by '_openstack user create udevtest --domain devtest --password xx_ - create project in the domain by '_openstack project create devmin --domain devtest_ - assign role 'admin' to the user on both the domain and the project: * _openstack role add admin --user udevtest --domain devtest_ * _openstack role add admin --project-domain devtest --project devmin --user udevtest_ then, using user's 'udevtest' credentials: OS_REGION_NAME=RegionOne OS_DEFAULT_DOMAIN=devtest OS_USER_DOMAIN_NAME=devtest OS_PROJECT_DOMAIN_NAME=devtest OS_PROJECT_NAME=devmin OS_USERNAME=udevtest OS_PASSWORD=x OS_AUTH_STRATEGY=keystone OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=http://controller:5000/v3 OS_INTERFACE=internal I'm able to get a list of all users and projects in 'default' domain and even more - add / delete users and projects in 'default' domain. In fact, user 'udevtest' has nothing to domain 'default', but assigned global role 'admin' - probably, that is the problem, because policy.json's rule 'admin_required' is just check for 'role:admin', which is true. On the other hand, if I create role 'admin' specific to domain 'devtest' and assign it to user on both domain and project in the domain, then I get error "*User f1c1cd3438c24255a2baa85f326dfc40 *(which is udevtest)*has no access to project 1dbbaf2fb0bc4d5da270e48d4a92bc62* (which is devmin)", so seems local roles doesn't matter. Is the only way (I hope it's legacy way :-) ) to change policy.json (as some pages on Internet were suggesting) or I'm doing something wrong? Thank you! -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [Keystone][PublicCloud] Introducing Adjutant, an OpenStack service for signups, user invites, password reset and more!
Hello OpenStack Community, I'd like to introduce to you all a service we have developed at Catalyst and are now ready to release to the OpenStack community in hopes that others may find it useful. As a public cloud provider we quickly ran into a bunch of little issues around user management, sign-ups, and other pieces of business logic that needed to fit into how we administer the cloud but didn't entirely make sense as additions to existing services. There were also a lot of actions we wanted to delegate to our customers but couldn't do without giving them too much power in Keystone, or wanted those actions to send emails, or extend to external non-OpenStack services. Enter Adjutant. Adjutant (previously called StackTask) was built as a service to allow us to create business workflows that can be exposed in some fashion over an API. A way for us to build reusable snippets of code that we can tie together, and a flexible and pluggable API layer we can expose those on. We needed these to be able to talk to our external systems, as well as our OpenStack services, and provide us some basic steps and in some cases the ability to require approval before an action completes. In many ways Adjutant also works as a layer around Keystone for us to build business logic around certain things we'd like our customers to be able to do in very limited ways. The service itself is built on Django with Django-Rest-Framework and is an API service with the gui component built as a ui plugin for Horizon that allows easy integration into an OpenStack dashboard. Adjutant, as the name implies, is a helper, not a major service, but one that smooths some situations and an easy place to offload some admin tasks that a customer or non-admin should be able to trigger in a more limited way. Not only that, but it stores the history of all these tasks, who asked for them, and when they were completed. Anything a user does through Adjutant is stored and able to be audited, with in future the ability for project admins to be able to audit their own tasks and see who of their users did something. Out of the box it provides the following functionality: * User invitation by users with the 'project_admin' or 'project_mod' role. o This will send out an email to the person you've invited with a submission token and let them setup their password and then grants them roles on your project. If their user exists already, will only require confirmation and then grant roles. * As a 'project_admin' or 'project_mod' you can list the users with roles on your project and edit their roles or revoke them from your project. * Let non-admin users request a password reset. o User will be emailed a token which will let them reset their password. * Basic signup o Let a user request a new project. Requires admin approval and will create a new project and user, granting default roles on the new project. Will reuse existing user if present, or send an email to the user to setup their password. * Let a user update their email address. o Will notify old email, and send a confirmation token to the new. Features coming in the future (most either almost done, or in prototype stages): * Forced password reset o users with 'project_admin' or 'project_mod'**can force a password reset for a given user in their projects o cloud admins can force password resets for users on their cloud. o changes user password to a randomly generated value and sends user a password reset token to their email. o user must reset before they can log in again. * Quota management for your project o As a 'project_admin' or 'project_mod' you can request a change in quota to a set of predefined sizes (as set in the Adjutant conf). Sizes allows you to increase multiple related quotas at the same time. You can move to adjacent sizes without approval a number of times in a configurable window (days), or an admin can approve your quota change as well. * Hierarchical Multi-Tenancy in a single domain environment o 'project_admin' to be able to create sub-projects off the current scoped project. o This uses HMT properly in Keystone but does not require an admin role and enforces a naming convention to ensure unique namespaces per sub-projects and somewhat avoids the project name uniqueness issues per domain. It's basically some wrapper logic for HMT in Keystone. o This also adds inherited role support to the already existing user invite and user role editing features. o some VERY basic sub-project quota (number of sub-projects allowed) via metadata stored on a project in Keystone, with quota calculations in Adjutant checking against number of sub-projects created in your WHOLE tree within given shifting window. T
