Adding some notes here from the discussion we had just now:
- *Fatal* and *Emergency* both need to be exposed to plugins, where
*Emergency* keeps traffic server down and *Fatal* will try and restart
(just like the core functions).
- When reading configs for the first time and fails, traffic server
should call *Emergency*, while on a config reload it should not call it
and fall back to the previous configuration.
If I forgot something we just talked about please add to this note @Alan
@Bryan.
Regards,
Fei Deng
On Tue, Jun 18, 2019 at 10:11 AM Fei Deng <duke8...@gmail.com> wrote:
> So this is what it looks like now:
>
> tsapi void
> TSEmergency(const char *fmt, ...)
> {
> va_list args;
>
> va_start(args, fmt);
> EmergencyV(fmt, args);
> va_end(args);
> }
>
> Regards,
> Fei Deng
>
>
> On Tue, Jun 18, 2019 at 9:41 AM Fei Deng <duke8...@gmail.com> wrote:
>
>> Yes, this is suggested by Alan and Susan, since sometimes we need plugins
>> to be able to abort and not try to restart (say if some important files are
>> missing). I'll change the name to TSEmergency().
>>
>> And I'll look at TSDebug and TSError, and make it similar to those.
>>
>> Regards,
>> Fei Deng
>>
>>
>> On Mon, Jun 17, 2019 at 5:59 PM Bryan Call <bc...@apache.org> wrote:
>>
>>> Looking how Emergency() vs ink_emergency() works. The only difference
>>> is Emergency() calls Diags::cleanup_func() with is only defined in
>>> traffic_manager.
>>>
>>> Here is the call stack for Emergency():
>>> Emergency > DiagsError > diags->error > error_va > ink_emergency_va >
>>> ::exit(UNRECOVERABLE_EXIT)
>>>
>>> Vs
>>> ink_emergency > ink_emergency_va > ::exit(UNRECOVERABLE_EXIT)
>>>
>>> -Bryan
>>>
>>>
>>> > On Jun 17, 2019, at 3:27 PM, Bryan Call <bc...@apache.org> wrote:
>>> >
>>> > I would assume he is going to be calling ink_emergency(), so it
>>> wouldn’t be a management API.
>>> >
>>> > Fei, can you add more details about what "This API is a wrapper for
>>> the "Emergency” call” is really going to do?
>>> >
>>> > -Bryan
>>> >
>>> >
>>> >> On Jun 17, 2019, at 3:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>> >>
>>> >>
>>> >>
>>> >>> On Jun 17, 2019, at 4:16 PM, Bryan Call <bc...@apache.org> wrote:
>>> >>>
>>> >>> I would recommend having it like TSDebug and TSError.
>>> >>>
>>> >>> tsapi void TSEmergency(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
>>> >>>
>>> >>> TSDebug and TSError:
>>> >>> tsapi void TSDebug(const char *tag, const char *format_str, ...)
>>> TS_PRINTFLIKE(2, 3);
>>> >>> tsapi void TSError(const char *fmt, ...) TS_PRINTFLIKE(1, 2);
>>> >>>
>>> >>
>>> >>
>>> >> What I don’t like with the original idea is that we’re putting
>>> management APIs (which we have ts/mgmt.h for) into the plugin APIs. There
>>> should be nothing stopping a plugin from using the management APIs I don’t
>>> think? If there is, that’s yet another issue.
>>> >>
>>> >> I feel reasonably strongly about not merging ts/hmgmt.h functionality
>>> into ts/ts.h.
>>> >>
>>> >> — Leif
>>> >>
>>> >>>
>>> >>> -Bryan
>>> >>>
>>> >>>
>>> >>>> On Jun 17, 2019, at 2:13 PM, Fei Deng <duke8...@apache.org> wrote:
>>> >>>>
>>> >>>> void TSEmergencyShutdown(const char *log_msg);
>>> >>>>
>>> >>>> This API is a wrapper for the "Emergency" call, which signals
>>> >>>> traffic_manager to not restart traffic_server after the shutdown,
>>> i.e. this
>>> >>>> call should be used when something has gone wrong and cannot be
>>> recovered
>>> >>>> by a restart.
>>> >>>
>>> >>
>>> >
>>>
>>>
