Consider renaming coreos-metadata

[bgilbert]

Feature Request

Environment

Any

Desired Feature

Consider renaming coreos-metadata. It seems that the project is drifting toward becoming a minimal, generic cloud agent, in which case the name is not very apt. In particular:

• The project will (hopefully!) be useful on other distros, so coreos isn't great.
• It does more than collect metadata, so metadata isn't great either.
• Given the above, COREOS_ is not great in output variable names. Changing it would be very user-visible and may not be feasible. We could output both old and new names for compatibility, but it's not clear that we could ever stop outputting the old names. We could drop the old names on non-CL distros, but users coming from CL will presumably have unit files and scripts that depend on the old names, and conversion tools (Container Linux migration tools fedora-coreos-tracker#48) may not be able to catch every use of them.

For a new project name, we could go the descriptive route with "platform-agent" or the like, but that doesn't seem very inspired. Maybe an arbitrary name would be better.

[ajeddeloh]

The-agent-formally-known-as-coreos-metadata. We could keep with the rocket/planet/earth related names (mantle, Ignition, rkt, etc). Or just pick a city in Massachusetts.

[bgilbert]

@lucab pointed out that we could direct the new output variables to a different file and eventually drop the old one. systemd will fail a service with a missing EnvironmentFile, so that at least breaks dependent services more loudly than removing variables from an existing file.

The existing file is /run/metadata/coreos, which probably needs a rename anyway.

[dustymabe]

"platform-agent"

👍 - unless someone can come up with something witty that fits I say let's just go with it.

[dustymabe]

Some ones that I thought of that apparently have software already named for it so we probably can't use:

• tugboat
• crankshaft
• piston (I think bgilbert thought of this one)

more:

• gasket - couldn't find any software projects with this name but probably doens't apply to what we're doing

Link for parts of an engine

[bgilbert]

Dumping some names from my notes:

• ullage
• hypergol
• glowplug
• nichrome
• bridgewire
• bellows
• pintle (as in pintle injector)
• carburetor
• parhelion

I kinda like "parhelion", but it's not ideal either.

[lucab]

From non-native speaker point of view, from the list above "glowplug" and "bridgewire" are the most obvious to pronounce on first encounter.

[dustymabe]

some more

• ether (looks like might be already taken)
• re-fuel
• afterburner
• takeoff
• liftoff (looks taken)
• airborne

[ajeddeloh]

I'm somewhat partial to afterburner. It sounds good, coreos-metadata runs after Ignition and it even has that in the name. It fits with our old "planets, the earth, and rockets" theme (btw IMO we should totally keep going on that theme, it's a good one).

EDIT: looks like there are a lot of afterburner projects (also scramjet)

[dustymabe]

EDIT: looks like there are a lot of afterburner projects (also scramjet)

dang

[dustymabe]

we could add a word in from to make it unique:

• platform-afterburner
• boot-afterburner
• startup-afterburner
• ignition-afterburner

or just call it afterburn or boot-afterburn

[jlebon]

I like a lot of the suggestions here. afterburn sounds pretty nice.

[bgilbert]

• pimento

[ajeddeloh]

pilotlight (only match is https://github.com/cwindeknecht/pilotlight with 6 commits from 2018)

[ghost]

• boot-bolts
• cogwheel

Something with bolt like bolt-data works maybe?

bridgewire and parhelion are nice, too. Would suggest nothing with burning or jokes will ensue if it's on fire. 😅

[bgilbert]

Okay, here's what I'm thinking:

Item	Value
Project name	Afterburn
Binary	afterburn
Units	afterburn.service, [email protected]
Output path	/run/metadata/afterburn
Environment variable prefix	AB_ (or AFTERBURN_?)
Azure agent name	com.coreos.afterburn

Yes/no?

[jlebon]

AB_ (or AFTERBURN_?)

I prefer the more explicit AFTERBURN_. All sounds good to me otherwise!