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 <apash...@mirantis.com > <mailto: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 <tel:%2B7%20%28985%29%20898%2057%2059> > Skype - waves_in_fluids > e-mail - apash...@mirantis.com <mailto:apash...@mirantis.com> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://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 <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 > -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __________________________________________________________________________ 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
