BMC and Host State Management Refactor

[Andrew Geissler]

On Tue, Nov 22, 2016 at 7:07 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> On Tue, 2016-11-22 at 11:23 -0600, Andrew Geissler wrote:
>> > On Mon, Nov 21, 2016 at 9:40 PM, Andrew Jeffery <andrew at 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 at jms.id.au> wrote:
>> > > > Hi Andrew and Josh,
>> > > >
>> > > > On Sat, Nov 19, 2016 at 7:01 AM, Andrew Geissler <geissonator at 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.
>

Ahh, ok I see your guys point now.  I could def rename the Desired
variables to something like DesiredHostTransition.  Maybe even make
their values verbs (TURN_ON, TURN_OFF, REBOOT)?  I could even knock of
the "Desired" part (i.e. HostTransition)?  I'm not real strong on it
either way.

>>  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