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 <apash...@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 - apash...@mirantis.com > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
