Target name refactoring

Rick Altherr raltherr at google.com
Sat Feb 25 08:31:54 AEDT 2017


I prefer the second.

On Fri, Feb 24, 2017 at 10:24 AM, Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

>
> > On Feb 24, 2017, at 11:41 AM, Rick Altherr <raltherr at google.com> wrote:
> >
> > nit: stop is a verb. Stopped is a state.
>
> Right.  So using one of the conventions below we’d have either:
>
> obmc-stop-host
> obmc-host-stopped
>
> or
>
> obmc-host-stop
> obmc-host-stopped
>
> I’m guessing the first person to reply with a preference will probably win.
>
> >
> > On Feb 24, 2017 5:59 AM, "Brad Bishop" <bradleyb at fuzziesquirrel.com>
> wrote:
> >
> > > On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel at jms.id.au> wrote:
> > >
> > > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <
> geissonator at gmail.com> wrote:
> > >> Some design decisions came out of my last set of changes in the
> > >> OpenBMC state area.  There was a proposal to rename our targets
> > >> responsible for booting and powering on/off the system.
> > >>
> > >> Currently we have this:
> > >> - PowerOn: obmc-power-chassis-on.target    obmc-chassis-start.target
> > >> - PowerOff: obmc-power-chassis-off.target    obmc-chassis-stop.target
> > >>  obmc-stop-host.target
> > >>
> > >> The obmc-power-chassis-*.targets are responsible for doing whatever is
> > >> required to apply pgood to the chassis.
> > >> The obmc-chassis-*.targets are responsible for starting and stopping
> > >> all host related services
> > >> The obmc-stop-host.target is where we have the soft power off service
> > >> (notify host of shutdown, wait for host to shutdown gracefully)
> > >>
> > >> Refactoring Proposal:
> > >> - First the chassis-start and chassis-stop target names don’t make
> > >> sense anymore with the new bmc, chassis, and host state break down’s
> > >> so:
> > >>  - Rename obmc-chassis-start.target to obmc-start-host.target
> > >>  - Rename obmc-chassis-stop.target to obmc-stop-host.target
> > >>  - Rename the current obmc-stop-host.target to
> obmc-shutdown-host.target
> > >
> > > Can I suggest putting the host before the action?
> > >
> > > obmc-host-stop
> > > obmc-host-start
> > > obmc-host-shutdown
> >
> > We have two types of targets, synchronization targets (for example
> network-pre.target),
> > and action targets(for example multi-user.target).  Sync targets are not
> directly
> > start/stoppable - they have to be started implicitly by systemd.  I
> would like a way
> > to be able to tell which one I am looking at from the name.  For example:
> >
> > obmc-stop-host # Action - stop the host.
> > obmc-host-stop # Sync - the host has been stopped.
> >
> > I had proposed this obmc-[verb]-[what] for actions and
> obmc-[what]-[state] to Andrew
> > privately..I’m fine with something else, again, as long as it is
> consistent.
> >
> > I can think of two conventions:
> >
> > obmc-[verb]-[what] for actions
> > obmc-[what]-[state] for sync points
> >
> > or
> >
> > obmc-[what]-[verb] for actions
> > obmc-[what]-[state] for sync points
> >
> > Either one is fine with me.  The former seems slightly easier to
> distinguish between
> > the two.
> >
> > >
> > >>
> > >> The target relationships are then the following:
> > >>
> > >> obmc-host-start.target requires obmc-power-chassis-on.target
> > >> obmc-shutdown-host.target requires obmc-stop-host.target requires
> > >> obmc-power-chassis-off.target
> > >
> > > obmc-host-start requires obmc-chassis-poweron
> > >
> > > obmc-host-shutdown requires obmc-host-stop requires
> obmc-chassis-poweroff
> > >
> > > I think the rest of your proposal sounds good, from what I understand.
> > >
> > > Cheers,
> > >
> > > Joel
> > >
> > >>
> > >> When a system goes to the quiesce target, the host state manager will
> > >> call the obmc-stop-host.target.  Otherwise, the host state service
> > >> will call the obmc-shutdown-host.target when power off is requested.
> > >>
> > >> Thoughts/Comments?
> > >> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170224/8494cad3/attachment.html>


More information about the openbmc mailing list