All of lore.kernel.org
 help / color / mirror / Atom feed
* Target name refactoring
@ 2017-02-20 22:20 Andrew Geissler
  2017-02-22  3:00 ` Joel Stanley
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Geissler @ 2017-02-20 22:20 UTC (permalink / raw)
  To: OpenBMC Maillist

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

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

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-20 22:20 Target name refactoring Andrew Geissler
@ 2017-02-22  3:00 ` Joel Stanley
  2017-02-24  4:05   ` Andrew Geissler
  2017-02-24 13:59   ` Brad Bishop
  0 siblings, 2 replies; 9+ messages in thread
From: Joel Stanley @ 2017-02-22  3:00 UTC (permalink / raw)
  To: Andrew Geissler; +Cc: OpenBMC Maillist

On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-22  3:00 ` Joel Stanley
@ 2017-02-24  4:05   ` Andrew Geissler
  2017-02-24  5:20     ` Andrew Jeffery
  2017-02-24 13:59   ` Brad Bishop
  1 sibling, 1 reply; 9+ messages in thread
From: Andrew Geissler @ 2017-02-24  4:05 UTC (permalink / raw)
  To: Joel Stanley; +Cc: OpenBMC Maillist

On Tue, Feb 21, 2017 at 9:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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
>

I believe Brad has a naming convention he's shooting for where the
verb comes second.  I'm somewhat agnostic on this but we just want to
be consistent.  With your proposal I'd probably have to rename the
chassis one's from obmc-power-chassis-on to obmc-chassis-power-on.

Thoughts Brad?

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-24  4:05   ` Andrew Geissler
@ 2017-02-24  5:20     ` Andrew Jeffery
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Jeffery @ 2017-02-24  5:20 UTC (permalink / raw)
  To: Andrew Geissler, Joel Stanley; +Cc: OpenBMC Maillist

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

On Thu, 2017-02-23 at 22:05 -0600, Andrew Geissler wrote:
> > On Tue, Feb 21, 2017 at 9:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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
> > 
> 
> I believe Brad has a naming convention he's shooting for where the
> verb comes second.  I'm somewhat agnostic on this but we just want to
> be consistent.  With your proposal I'd probably have to rename the
> chassis one's from obmc-power-chassis-on to obmc-chassis-power-on.
> 
> Thoughts Brad?

Whatever the case, ack from me on your general proposal, so long as the
names are consistent.

Andrew

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

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-22  3:00 ` Joel Stanley
  2017-02-24  4:05   ` Andrew Geissler
@ 2017-02-24 13:59   ` Brad Bishop
  2017-02-24 16:41     ` Rick Altherr
  1 sibling, 1 reply; 9+ messages in thread
From: Brad Bishop @ 2017-02-24 13:59 UTC (permalink / raw)
  To: Joel Stanley; +Cc: Andrew Geissler, OpenBMC Maillist


> On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> 
> On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-24 13:59   ` Brad Bishop
@ 2017-02-24 16:41     ` Rick Altherr
  2017-02-24 18:24       ` Brad Bishop
  0 siblings, 1 reply; 9+ messages in thread
From: Rick Altherr @ 2017-02-24 16:41 UTC (permalink / raw)
  To: Brad Bishop; +Cc: Joel Stanley, OpenBMC Maillist

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

nit: stop is a verb. Stopped is a state.

On Feb 24, 2017 5:59 AM, "Brad Bishop" <bradleyb@fuzziesquirrel.com> wrote:

>
> > On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> >
> > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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
>

[-- Attachment #2: Type: text/html, Size: 4175 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-24 16:41     ` Rick Altherr
@ 2017-02-24 18:24       ` Brad Bishop
  2017-02-24 21:31         ` Rick Altherr
  0 siblings, 1 reply; 9+ messages in thread
From: Brad Bishop @ 2017-02-24 18:24 UTC (permalink / raw)
  To: Rick Altherr; +Cc: OpenBMC Maillist


> On Feb 24, 2017, at 11:41 AM, Rick Altherr <raltherr@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@fuzziesquirrel.com> wrote:
> 
> > On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> >
> > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <geissonator@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-24 18:24       ` Brad Bishop
@ 2017-02-24 21:31         ` Rick Altherr
  2017-02-24 22:41           ` Andrew Geissler
  0 siblings, 1 reply; 9+ messages in thread
From: Rick Altherr @ 2017-02-24 21:31 UTC (permalink / raw)
  To: Brad Bishop; +Cc: OpenBMC Maillist

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

I prefer the second.

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

>
> > On Feb 24, 2017, at 11:41 AM, Rick Altherr <raltherr@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@fuzziesquirrel.com>
> wrote:
> >
> > > On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel@jms.id.au> wrote:
> > >
> > > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler <
> geissonator@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
>

[-- Attachment #2: Type: text/html, Size: 5292 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Target name refactoring
  2017-02-24 21:31         ` Rick Altherr
@ 2017-02-24 22:41           ` Andrew Geissler
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Geissler @ 2017-02-24 22:41 UTC (permalink / raw)
  To: Rick Altherr; +Cc: Brad Bishop, OpenBMC Maillist

ok so refactored action targets and their relationships would look like this

obmc-host-start
  -> Requires: obmc-chassis-power-on

obmc-host-shutdown
  -> Requires: obmc-host-stop
    -> Requires: obmc-chassis-power-off

The synch targets would follow similar conventions, I may break that
into a separate task since the action targets are what users interact
with and I'd like to get done ASAP.

Andrew

On Fri, Feb 24, 2017 at 3:31 PM, Rick Altherr <raltherr@google.com> wrote:
> I prefer the second.
>
> On Fri, Feb 24, 2017 at 10:24 AM, Brad Bishop <bradleyb@fuzziesquirrel.com>
> wrote:
>>
>>
>> > On Feb 24, 2017, at 11:41 AM, Rick Altherr <raltherr@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@fuzziesquirrel.com>
>> > wrote:
>> >
>> > > On Feb 21, 2017, at 10:00 PM, Joel Stanley <joel@jms.id.au> wrote:
>> > >
>> > > On Tue, Feb 21, 2017 at 8:50 AM, Andrew Geissler
>> > > <geissonator@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
>
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-02-24 22:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-20 22:20 Target name refactoring Andrew Geissler
2017-02-22  3:00 ` Joel Stanley
2017-02-24  4:05   ` Andrew Geissler
2017-02-24  5:20     ` Andrew Jeffery
2017-02-24 13:59   ` Brad Bishop
2017-02-24 16:41     ` Rick Altherr
2017-02-24 18:24       ` Brad Bishop
2017-02-24 21:31         ` Rick Altherr
2017-02-24 22:41           ` Andrew Geissler

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.