Open Stack

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

On Thu, Feb 12, 2015 at 7:38 AM, Andrew Pashkin <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
> Skype - waves_in_fluids
> e-mail - apashkin at mirantis.com
>
> __________________________________________________________________________
> 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
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/1c0a636c/attachment.html>