Name changes for service module names

dongahn commented 4 years ago

As part of a PR #481 review, @garlick suggested:

You have two modules named qmanager and resource. Should they be named with a common prefix to indicate that they are part of a single scheduler implementation, like sched-full-qmanager and sched-full-resource? (substitute something more creative and cool sounding for "full" :-)

As I think about this, it may be good to have an actual cool name for the scheduler components and use that as the prefix for the services.

dongahn commented 4 years ago

Our resource infrastructure starts to look pretty solid, and I think I should try to write up a paper on the core technologies sooner rather than later. It helps have a good name for that purpose as well as the issue described above. So here are two proposal.

GANTT (Graph’s Arbitrable Nodes and Time Traversers) This will make our service modules look like: gantt-resource and gantt-qmanager. The prefix then can differentiate our full scheduler with sched-simple or test scheduler in flux-core.
GATES (Graph Aided Task Execution Scheduler or other backronym) I just learned that "fluxgate" is actually a thing so this may work well with Flux although the initial feedback I got from @SteVwonder, Frank and Joe were not that great. https://en.wikipedia.org/wiki/Fluxgate_compass

Ultimately, we should refactor all the flux-core-agnostic components and package them into a separate repo so that it can be contributed and used by other projects beyond Flux as a reusable general purpose componen. This will include the kubenetes scheduler plugin that @cmisale is currently working on. At the last call, she said she can do a go binding for our high level resource API.

At that point, flux-sched will become a thin layer that integrates these general purpose components into flux-core.

Thoughts on the names?

grondo commented 4 years ago

I respectfully submit:

GAUSS - Graph Abstraction for Universal System Scheduling

The U could also stand for Uncompromising, Undifferentiated, Unconfined, Unlimited, etc.

(I know you weren't really looking for new names, but I couldn't resist, sorry)

dongahn commented 4 years ago

Thanks @grondo. New name proposals are appreciated since I still have time to decide the best one!

dongahn commented 4 years ago

Maybe Graph-Aided... instead of Abstraction... Did you name this after a mathematician?

grondo commented 4 years ago

Yes, mathematician, physicist, and also a "gauss" is a unit of measurement for magnetic flux density. Possibly there are already a lot of things called Gauss though...

dongahn commented 4 years ago

I like its tie to flux. Gantt is also a mathematician (or maybe a engineer) who is known for project scheduling but there are lots of things called Gantt as well.

dongahn commented 4 years ago

A few more names:

Aion: Greek god for time (No acronym)
Ion: an atom or molecule with a net electric charge due to the loss or gain of one or more electrons.

I think these can go well with flux given what fluxion is: https://en.wikipedia.org/wiki/Fluxion. It can represent what the core of resource infrastructure does as well: we keep track of instantaneous resource changes at each and every scheduled points in time.

aion-resource aion-qmanager

Or

ion-qmanager ion-resource

dongahn commented 4 years ago

I sort of like fluxion as the new scheduler name because of its association with flux. For now, I will go with ion-manager and ion-resource as the module names and see how it sticks. I think, having this name will help me write a paper as planned early Aug.

garlick commented 4 years ago

Aww I was rooting for the GUASS backronym :-(

On Fri, Jul 26, 2019 at 9:10 AM Dong H. Ahn notifications@github.com wrote:

I sort of like fluxion as the new scheduler name because of its association with flux. For now, I will go with ion-manager and ion-resource as the module names and see how it sticks. I think, having this name will help me write a paper as planned early Aug.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/flux-framework/flux-sched/issues/485?email_source=notifications&email_token=AABJPW6OM5J4F4FZBPSETLTQBMOYVA5CNFSM4H6NH6G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25BOHA#issuecomment-515512092, or mute the thread https://github.com/notifications/unsubscribe-auth/AABJPW5JAYE5RGGSYMGIMXLQBMOYVANCNFSM4H6NH6GQ .

dongahn commented 4 years ago

Aww I was rooting for the GUASS backronym :-(

I liked that too.

It's just that the meaning of fluxion -- The fluxion of a "fluent" (a time-varying quantity, or function) is its instantaneous rate of change, or gradient, at a given point -- was much more representative of what we are doing.

garlick commented 4 years ago

flux-framework/flux-core#2908 proposes to add a new resource module which would conflict with flux-sched's resource module. It would helpful if we accelerate the name change proposed in this issue, as the new module is on the critical path for our next milestone.

dongahn commented 4 years ago

Sounds good to me. Once I do a PR for multi-queue for qmanager, I will look into it. Pretty straightforward change. But it will touch quite a bit.

garlick commented 4 years ago

Following up on our meeting discussion:

I suggested maybe just change internal module name would allow the flux-core resource module to get merged with the name 'resource", but actually that impacts your RPC topic strings, config table names, etc, so maybe it's not that helpful of a step. It's most of the work.

dongahn commented 4 years ago

We're pretty close to land PR #645 and #646.

Then, I need a few more days to tighten up the loosen ends for PR #649. When that lands, this will be a good state to add this name change.

There is still a big resiliency PR #470. But given that it will take a lot of time to merge all the change from the above three PRs into that and to review this thoroughly, we should defer the merging of that PR after the name change. It will be painful but we will just have to roll with it.

garlick commented 4 years ago

I noticed over in flux-framework/flux-core#2918 you were using fluxion-resource as the new name. Above I proposed a sched- prefix for both modules to make it obvious that this is a scheduler implementation. Is that OK, e.g. sched-fluxion-resource and sched-fluxion-qmanager for the new names?

dongahn commented 4 years ago

I guess.

But why so long name? Can Fluxion be branded and familiarized after we use it for awhile such that people would know it provides a scheduler implementation?

garlick commented 4 years ago

Can Fluxion be branded and familiarized after we use it for awhile such that people would know it provides a scheduler implementation?

Even "coke" was "coca cola" at first, so it may be assuming a lot :-)

dongahn commented 4 years ago

Do you want the module SO to be named that way or the mod_name and topic strings all have that prefix as well?

If we were to use long names, I wonder if fluxion-sched-resource and fluxion-sched-qmanager is a bit better. The fluxion front end tool can be named as flux ion-sched [resource | qmanager] as opposed to flux sched-fluxion [resource | qmanager].

garlick commented 4 years ago

We have sched-simple and connector-local, so it seems like the convention we've established is general to specific, left to right. So I would vote sched-fluxion-* or cola-coca.

It's probably the most obvious if so name, MOD_NAME, and rpc names are the same, but I think the MOD_NAME is the more visible one (e.g. for flux module command)

dongahn commented 4 years ago

general to specific

sched-resource-fluxion sched-qmanager-fluxion

Just kidding :-).

I'm okay with sched-fluxion-* We'll see where it will take us when we name the front end command for Fluxion.

garlick commented 4 years ago

flux ion ... works for me :-)

Could also go with sched-ion-* for the MOD_NAME and reserve the pun for the front end command...

dongahn commented 4 years ago

W/ long names, flux module list needs to widen its first column:

ahn1@49674596c035:/usr/src$ flux module list
Module                   Size Digest  Idle  S Service
content-sqlite        1145088 5FF96CF    1  S content-backing,kvs-checkpoint
job-ingest            1248840 6059023    1  S
kvs                   1598704 40AE8B8    0  S
barrier               1137432 88E330F    1  S
job-info              1390032 1428F9C    1  S
job-exec              1310896 EBB1F53    1  S
connector-local       1129864 E17BF29    0  R
cron                  1220232 416975B    0  S
sched-fluxion-resour 19140768 F025AC0    1  S
kvs-watch             1324632 D7998BF    1  S
sched-fluxion-qmanag  3905008 A71A546    1  S sched
aggregator            1153792 27CB3C5    1  S
job-manager           1369520 0721746    1  S

dongahn commented 3 years ago

Done as part of PR #655

flux-framework / flux-sched

Name changes for service module names #485