Re: BMC and Host State Management Refactor

[Andrew Jeffery <andrew@aj.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

On Tue, 2016-11-22 at 11:23 -0600, Andrew Geissler wrote:
> > On Mon, Nov 21, 2016 at 9:40 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > On Mon, 2016-11-21 at 20:28 -0600, Andrew Geissler wrote:
> > > > > > > > On Sun, Nov 20, 2016 at 11:55 PM, Joel Stanley <joel@jms.id.au> wrote:
> > > > Hi Andrew and Josh,
> > > > 
> > > > On Sat, Nov 19, 2016 at 7:01 AM, Andrew Geissler <geissonator@gmail.com> wrote:
> > > > > Josh and I are working two stories this sprint that deal with
> > > > > refactoring the bmc and host state management code out of skeleton
> > > > > (#772/#783).  Here’s the proposal on this work.
> > > > 
> > > > Thanks for sending out your plan, this is great. I have a few comments
> > > > that came up as I was reading.
> > > > 
> > > > > The overall design for both state management objects is that they will
> > > > > provide a set of properties on which to operate.
> > > > > - DesiredState
> > > > > - CurrentState
> > > > > 
> > > > > CurrentState will be a read only property.
> > > > 
> > > > You've chosen to make the desired and current states be separate,
> > > > which works. Another option would be to have them be the same list of
> > > > states, so you know that when current==desired you're not waiting on
> > > > anything to happen. What do you think?
> > > > 
> > > 
> > > Hmmm, I'm thinking from a DBUS/REST api perspective here.  2 seems
> > > more intuitive, but also I don't think I understand your proposal
> > > fully :)
> > 
> > I think you might be misinterpreting. I don't think Joel was suggesting
> > you eliminate one of the DesiredState or CurrentState "variables",
> > rather that the /types/ of the CurrentState and DesiredState variables
> > be equal. That is, that the same set of states can be assigned to both.
> > 
> 
> I see now.  I'm still not seeing any huge advantages on either
> proposal over my original. 

The advantage I see in Joel's proposal is that we have fewer types
involved in the problem. The alternative (as mentioned below) is you
rename DesiredState to Transition, in which case I think what you are
suggesting is okay. Transitions and states are distinct and well
defined concepts.

I don't like the idea of "desiring" a state that doesn't exist. Joel's
initial question suggests he thinks along these lines as well.

>  I think I'm just going to stick with it
> for now since there are times where the valid states associated with
> each (Desired vs. Current) are different

Can you expand on this to make it clear what you are arguing for?

>  and I think having the two as
> I've defined is a bit more user friendly.

In what way?

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]