Service management of Sage - D

[YU_Xinjie]

(12-06-2016 01:35 PM)lingu Wrote:  

(12-06-2016 12:32 PM)YU_Xinjie Wrote:  I suggest we add a "sage config VAR_NAME" command, so that app of Sage (such as GLAD) can query the config value easily.

We already have a way to let Sage store and report k/vs. Why can't we use the existing way?

Do you mean "query Sage"? I am okay to use it. But I still do not know how to use it. Let us discuss it here: http://tab.d-thinker.org/showthread.php?...6#pid30046

Quote:

Quote:It is needed for many situations:
1. We need to use "atp_cnt" to set up glad_size of GLAD.

Where do we need to use glad_size? I am curious to know.

I replied in http://tab.d-thinker.org/showthread.php?...6#pid30046

Quote:

Quote:2. GLAD needs the config.node info.

In which case?

It is needed in the shuffle tmp implementation. It is okay to delay the config.node info fetching.

[lingu]

(12-06-2016 03:32 PM)YU_Xinjie Wrote:  

(12-06-2016 01:35 PM)lingu Wrote:  

(12-06-2016 12:32 PM)YU_Xinjie Wrote:  I suggest we add a "sage config VAR_NAME" command, so that app of Sage (such as GLAD) can query the config value easily.

We already have a way to let Sage store and report k/vs. Why can't we use the existing way?

Do you mean "query Sage"? I am okay to use it. But I still do not know how to use it. Let us discuss it here: http://tab.d-thinker.org/showthread.php?...6#pid30046

glad can query sage config's values. We can use the same mechanism to let other apps query sage config values.

Or maybe I misunderstood. Did you mean we let an app store the app's config value in sage? That's certainly a good idea. Of course, we need to discuss it more seriously because it is a new mechanism.

Quote:

Quote:

Quote:2. GLAD needs the config.node info.

In which case?

It is needed in the shuffle tmp implementation. It is okay to delay the config.node info fetching.

It is a bit surprising to me. I will try to take a look at the shuffle design when there is a chance...

[lingu]

Is the users' info officially in http://tab.d-thinker.org/showthread.php?tid=6197 ?

I suggest we remove 'U' in the tag in the title and point to that thread in the overview for the users' info.

[lingu]

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  Users' info

http://tab.d-thinker.org/showthread.php?tid=5694

That links to OMUD info... seems strange.

[YU_Xinjie]

(01-12-2017 06:55 PM)lingu Wrote:  

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  Users' info

http://tab.d-thinker.org/showthread.php?tid=5694

That links to OMUD info... seems strange.

Yes. The reason is we have 2 types of readers:
1. hututa persons like Zhiqiang.
2. shufangkeji persons like you & me.

So we need to prepare 2 overview threads for them.
Essentially, the overview in Rar is the one have full info.
So I propose not to have 2 overview threads by the method in http://tab.d-thinker.org/showthread.php?...5#pid31325

[YU_Xinjie]

@lingu Please review.

The driving example: http://tab.d-thinker.org/showthread.php?...9#pid41989
We needs to let sage complains to mayday when sage fails.

The design is as follows:

(07-12-2016 05:54 PM)YU_Xinjie Wrote:  sage start

Start a sage_screen to run script start_sage.
start_sage script looks like this:

Quote:...

do_start() {
./detect_listen.sh &
make run, which would calls `dt run sage-svc $sage_base/config.pcf`
if return non-0 {
.. mayday_msg = "SAGE FATAL EXIT. "
.. check the stdout log of Sage. If it is because one of the task failure {
.... find the container (DT) log of this task
.... mayday_msg += fetch the task command line from the container log
.. }

.. #Do some clean work
.. kill (clean) the screen session of "sage wake"
.. kill (clean) the screen session of "sage start", namely the current session.
}
}
...

[lingu]

(06-02-2017 06:24 PM)YU_Xinjie Wrote:  @lingu Please review.

The driving example: http://tab.d-thinker.org/showthread.php?...9#pid41989
We needs to let sage complains to mayday when sage fails.

The design is as follows:
[quote='YU_Xinjie' pid='11533' dateline='1468313653']
sage start

Start a sage_screen to run script start_sage.
start_sage script looks like this:

Quote:...

do_start() {
./detect_listen.sh &
make run, which would calls `dt run sage-svc $sage_base/config.pcf`
if return non-0 {
.. mayday_msg = "SAGE FATAL EXIT. "

It is okay to write a mayday log message on this case.

[quote]
.. check the stdout log of Sage. If it is because one of the task failure {
.... find the container (DT) log of this task
.... mayday_msg += fetch the task command line from the container log
.. }

But don't parse stdout log. I wonder why we dont have a simpler way.

The idea of mayday log is to simplfy log examination. If a task fails, the task should write something in the mayday log. Then the calling routine's job is to just output mayday log. This avoids parsing think containers' log files.

If think containers dont write mayday log now, we should improve them so that they write mayday log files. If we try to let another program help them write mayday log files, that would be a painful complicated solution.

Quote:.. #Do some clean work
.. kill (clean) the screen session of "sage wake"
.. kill (clean) the screen session of "sage start", namely the current session.
}[/u]
}
...

In many cases, we want to keep those screens for debugging. Pls make the killing of the screens controllable by some options. The default behavior can be to kill the screens, but with some options we should be able to keep the screens upon failure.

Those two screens seem to have the same name. It is very confusing. Pls fix it.

[lingu]

The src of the sage program is in cod://sage/src/service/bin/sage

[lingu]

The sage program begins with the following logic.

Code:

base=current dir
LearnPcf $base/config.pcf
ips=$base/hosts.ips

I suggest we also learn /thinker/etc/soft/sage/mic.pcf but $base/config.pcf take precedence over /thinker/etc/soft/sage/mic.pcf

RR xwcwt

[xwcwt]

(05-08-2019 10:01 PM)lingu Wrote:  The sage program begins with the following logic.

Code:

base=current dir
LearnPcf $base/config.pcf
ips=$base/hosts.ips

I suggest we also learn /thinker/etc/soft/sage/mic.pcf but $base/config.pcf take precedence over /thinker/etc/soft/sage/mic.pcf

RR xwcwt

Good to me.

Also I feel it will be

Code:

modname = sage
LearnPcf /thinker/etc/soft/$modname/mic.pcf before LearnPcf $base/config.pcf

Update into head-post.