[openstack-dev] [Murano] [API WG] Environment status

Ryan Brown rybrown at redhat.com
Thu Feb 12 17:14:08 UTC 2015


On 02/12/2015 10:52 AM, Georgy Okrokvertskhov wrote:
> I think this is a good case for API WG as statuses of entities should be
> consistent among OpenStack APIs. As I recall, we are mixing two
> different statuses for environments. The first dimension for environment
> status is its content status: NEW, CONFIGURING, READY
> The second dimension is deployment status after Murano engine executes
> deployment action for this environment with statuses: NOT DEPLOYED,
> DEPLOYING, SUCCESS, FAIL
> 
> Thanks
> Gosha
> 
One place we use these pretty extensively is in Heat and Ceilometer.

Ceilometer: OK, INSUFFICIENT_DATA, ALARM

In heat we have the notion of status and actions. Actions are something
you do, a status is how the action has resolved.

Actions: INIT, CREATE, DELETE, UPDATE, ROLLBACK, SUSPEND, RESUME, ADOPT,
SNAPSHOT, CHECK

Status: IN_PROGRESS FAILED COMPLETE

This is presented to the user combined (e.g. INIT_COMPLETE or
ROLLBACK_FAILED) together.

> On Thu, Feb 12, 2015 at 7:38 AM, Andrew Pashkin <apashkin at mirantis.com
> <mailto:apashkin at mirantis.com>> wrote:
> 
>     Initiall my interest to that problem was caused by the bug [1] due
>     to whose
>     once environment was deployed with failure it stays forever with
>     that status
>     even if it have been deployed sucessfully later.
> 
>     For now status determination happens in three stages:
> 
>     - If at least one of all sessions of env, regardless of version, is in
>       DEPLOYING/DELETING or DEPLOY_FAILURE/DELETE_FAILURE states - state
>     of that
>       session taken as state of environment. Sessions prioritized by
>     version and
>       midification date.
>     - If there is no such sessions, but  at least one is in OPENED state -
>       environment state will be PENDING.
>     - Otherwise environment will have READY status.
> 
>     Accordingly to that - once session was deployed with failure - it stays
>     in that
>     status even if it was deployed successfully later.
> 
>     In UI statuses are taken directly from API except another "calculated"
>     status
>     NEW. Environment matches status NEW if it has version = 0 and it has
>     apps with
>     status 'pending' [2].
> 
>     After discussion inside Mirantis Murano team we came to these thoughts:
>     - We need to remove statuses that does not related to deployment
>     (PENDING).
>     - Introduce NEVER_DEPLOYED (or NEW) status.
>     - Change READY to DEPLOYED.
>     - Possibly we need to keep state in Environment table in DB and no
>     calculate it
>       queriyng session every time.
> 
>     PENDING status was needed to indicate that another user do something
>     with the
>     environment. But it was decided, that this information must be placed
>     somwhere
>     else, to not be in coflict with deployment status. Another proposal
>     was to
>     additionaly show if environment has some "dirty"/not-deployed
>     changes in it.
> 
>     First of all let's discuss quick fix of the alghorithm of
>     Environment status
>     matching [3]. I propose to take status of last modified session as
>     status of an
>     environment.
> 
>     At second let's discuss overall situation and more extensive changes
>     that we
>     might want introduce.
> 
> 
>     [1] https://bugs.launchpad.net/murano/+bug/1413260
>     [2]
>     https://github.com/stackforge/murano-dashboard/blob/master/muranodashboard/environments/api.py#L140-140
>     [3]
>     https://github.com/stackforge/murano/blob/017d25f49e60e18365a50756f524e15f8d4fa78a/murano/db/services/environments.py#L62
> 
>     --
>     With kind regards, Andrew Pashkin.
>     cell phone - +7 (985) 898 57 59 <tel:%2B7%20%28985%29%20898%2057%2059>
>     Skype - waves_in_fluids
>     e-mail - apashkin at mirantis.com <mailto:apashkin at mirantis.com>
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.



More information about the OpenStack-dev mailing list