Re: [openstack-dev] [Ironic] *ED states strike back
Ruby, What you say makes sense to me. On keeping things consistent. So sounds good to me to always use them and not have them be optional. John On Thu, Feb 19, 2015 at 9:32 AM, Ruby Loo wrote: > I think that if there is a use case for an *ED state, then we should have > it. And if we have one *ED state, I think it makes sense (and is > consistent) to have them for all the active states. > > If we have *ED states, I would prefer that we add them in when the active > state is added. So add ING, ED, FAIL. If a particular > driver has nothing it wants to do in an *ED state, it can cause a > transition from the *ED state to the passive/stable state. > > I don't want the *ED states to be optional because that puts the onus on > the developer that needs the *ED state, to add it in (assuming they are > aware that this is possible) and put in whatever plumbing might be needed. > Which may mean that they'd have to modify code in another driver, that > didn't need *ED in the first place. (If an *ED state is added, all drivers > using that active state should handle the *ED state too because it is in > the state machine and I'd rather not complicate things by having state-ING > -> state-ED -> stable-state and state-ING -> stable-state. > > --ruby > > __ > 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 > > __ 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
Re: [openstack-dev] [Ironic] *ED states strike back
I think that if there is a use case for an *ED state, then we should have it. And if we have one *ED state, I think it makes sense (and is consistent) to have them for all the active states. If we have *ED states, I would prefer that we add them in when the active state is added. So add ING, ED, FAIL. If a particular driver has nothing it wants to do in an *ED state, it can cause a transition from the *ED state to the passive/stable state. I don't want the *ED states to be optional because that puts the onus on the developer that needs the *ED state, to add it in (assuming they are aware that this is possible) and put in whatever plumbing might be needed. Which may mean that they'd have to modify code in another driver, that didn't need *ED in the first place. (If an *ED state is added, all drivers using that active state should handle the *ED state too because it is in the state machine and I'd rather not complicate things by having state-ING -> state-ED -> stable-state and state-ING -> stable-state. --ruby __ 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
Re: [openstack-dev] [Ironic] *ED states strike back
Can the *ED states be optional? If a state would be a NO-OP, then don't use it. But if it is useful then use it. It seems ugly to me to just have two 'change state' calls to move it through the *ED state. If an *ED state needs to be added later I think it could be added without too much difficulty and the code will be cleaner without having 'no-op' states. WDYT? John On Thu, Feb 19, 2015 at 7:25 AM, Dmitry Tantsur wrote: > Hi everyone! > > On one of our meetings [1] we agreed on keeping *ED states (DELETED, > INSPECTED, CLEANED, etc) as no-ops for now. Since then, however, the > inspection patch [2] got several comments from cores requesting removal of > INSPECTED state. That was done by Nisha. > > Today we decided to approve [2] and bring the discussion here. We can > always add the state later, and blocking this patch again would be a bit > unfair IMO. We'll create a follow-up to [2] if we decide that we need > INSPECTED state. > > So now, are we keeping/adding these *ED states to our state machine? I > personally agree with what was discussed on the meeting, namely: > 1. Keep *ED states > 2. Make them no-ops, so that code that does INSPECTING -> MANAGEABLE right > now will do INSPECTING -> INSPECTED -> MANAGEABLE instead. > > Having INSPECTED is also useful for distinguish between OOB case (when > inspect_hardware returns after having everything done) and in-band case > (when inspect_hardware returns after initializing inspection). We could use > return value of inspect_hardware being INSPECTING or INSPECTED. > > WDYT? > > Dmitry. > > [1] http://eavesdrop.openstack.org/meetings/ironic/2015/ > ironic.2015-02-09-17.00.log.html starting 17:47 > [2] https://review.openstack.org/#/c/147857/ > > __ > 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 > __ 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
[openstack-dev] [Ironic] *ED states strike back
Hi everyone! On one of our meetings [1] we agreed on keeping *ED states (DELETED, INSPECTED, CLEANED, etc) as no-ops for now. Since then, however, the inspection patch [2] got several comments from cores requesting removal of INSPECTED state. That was done by Nisha. Today we decided to approve [2] and bring the discussion here. We can always add the state later, and blocking this patch again would be a bit unfair IMO. We'll create a follow-up to [2] if we decide that we need INSPECTED state. So now, are we keeping/adding these *ED states to our state machine? I personally agree with what was discussed on the meeting, namely: 1. Keep *ED states 2. Make them no-ops, so that code that does INSPECTING -> MANAGEABLE right now will do INSPECTING -> INSPECTED -> MANAGEABLE instead. Having INSPECTED is also useful for distinguish between OOB case (when inspect_hardware returns after having everything done) and in-band case (when inspect_hardware returns after initializing inspection). We could use return value of inspect_hardware being INSPECTING or INSPECTED. WDYT? Dmitry. [1] http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-02-09-17.00.log.html starting 17:47 [2] https://review.openstack.org/#/c/147857/ __ 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
