BMC and Host State Management Refactor
Andrew Jeffery
andrew at aj.id.au
Wed Nov 23 12:07:59 AEDT 2016
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.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161123/a0ca9490/attachment.sig>
More information about the openbmc
mailing list