[NEW PORT] sysutils/google-compute-engine: User daemon for Google Compute Engine

[ultima]

Summary

Google Compute Engine offers scripts and daemons which runs in the
background and provides the following services:

• Accounts daemon to setup and manage user accounts, and to enable SSH key based authentication.
• Clock skew daemon to keep the system clock in sync after VM start and stop events.
• Instance setup scripts to execute VM configuration scripts during boot.
• IP forwarding daemon that integrates network load balancing with forwarding rule changes into the guest.
• Metadata scripts to run user provided scripts at VM startup and shutdown.
• Network setup service to enable multiple network interfaces on boot.

WWW: https://github.com/GoogleCloudPlatform/compute-image-packages

PR\: 219687
Submitted by\: Helen Koike (maintainer)
Reviewed by\: lifanov (mentor), matthew (mentor), koobs, sunpoet, swills
Approved by\: lifanov (mentor), matthew (mentor)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

Test Plan

portlint:
WARN: /usr/ports/sysutils/py-google-compute-engine/pkg-message: possible use of absolute pathname "/etc/rc.conf".
0 fatal errors and 1 warning found.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

[ultima]

This is a big one, went through it a few times, it should be ready.

[ultima]

sysutils/py-google-compute-engine/files/google_accounts_daemon.in

21 ↗

(On Diff #32231)

One thing I am wondering if this is acceptable to have an rc script default on like this. Obviously is not standard but I can see a valid reason. Didn't see any strict policy on it in the PHB so I assume it is fine.

[matthew]

The number of rc scripts this port installs is bizarre. Is it really necessary to have so many?

The judgement should be "is what this script controls something that could be run independently of what
the other scripts control?" If you're always going to run "foo" and "bar" together, then maybe you should
have a single "foobar" RC script. As noted, the RC script should control both startup and shutdown of
a service. RC scripts should also always default to disabled on install from pkg -- that's a longstanding
project policy, that the system admin is who decides what gets run.

sysutils/py-google-compute-engine/files/google_accounts_daemon.in

21 ↗

(On Diff #32231)

No -- the default here is always "NO". It's up to the admin to enable daemons.

sysutils/py-google-compute-engine/files/google_clock_skew_daemon.in

21 ↗

(On Diff #32231)

Should default to "NO"

sysutils/py-google-compute-engine/files/google_instance_setup.in

20 ↗

(On Diff #32231)

Should default to "NO"

sysutils/py-google-compute-engine/files/google_ip_forwarding_daemon.in

21 ↗

(On Diff #32231)

Should default to "NO"

sysutils/py-google-compute-engine/files/google_network_setup.in

20 ↗

(On Diff #32231)

Should default to "NO"

sysutils/py-google-compute-engine/files/google_shutdown_scripts.in

5 ↗

(On Diff #32231)

Why do you have separate 'shutdown' and 'startup' RC scripts? One script should handle both startup and shutdown for each service.

21 ↗

(On Diff #32231)

Should default to "NO"

sysutils/py-google-compute-engine/files/google_startup_scripts.in

5 ↗

(On Diff #32231)

Merge this with 'google_startup'

20 ↗

(On Diff #32231)

Should default to "NO"

[ultima]

In D12077#250546, @matthew wrote:

The number of rc scripts this port installs is bizarre. Is it really necessary to have so many?

The judgement should be "is what this script controls something that could be run independently of what
the other scripts control?" If you're always going to run "foo" and "bar" together, then maybe you should
have a single "foobar" RC script. As noted, the RC script should control both startup and shutdown of
a service. RC scripts should also always default to disabled on install from pkg -- that's a longstanding
project policy, that the system admin is who decides what gets run.

Yeah, this port will probably break a record. Is it necessary? good question... It seems this is how google wanted to make the tools for they're compute engine. The creator of the port was considering removing the startup/shutdown script, it was kept to preserve the the style from the upstream project.
https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/google_compute_engine_init/sysvinit

Default NO is a standard, duly noted!

[matthew]

In D12077#250582, @ultima wrote:

In D12077#250546, @matthew wrote:

The number of rc scripts this port installs is bizarre. Is it really necessary to have so many?

The judgement should be "is what this script controls something that could be run independently of what
the other scripts control?" If you're always going to run "foo" and "bar" together, then maybe you should
have a single "foobar" RC script. As noted, the RC script should control both startup and shutdown of
a service. RC scripts should also always default to disabled on install from pkg -- that's a longstanding
project policy, that the system admin is who decides what gets run.

Yeah, this port will probably break a record. Is it necessary? good question... It seems this is how google wanted to make the tools for they're compute engine. The creator of the port was considering removing the startup/shutdown script, it was kept to preserve the the style from the upstream project.
https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/google_compute_engine_init/sysvinit

Default NO is a standard, duly noted!

Google are not necessarily expert at how the FreeBSD RC system works. I can't tell from inspection how independent all these RC scripts
really are, so we'd have to go by what the maintainer tells us. Although the separated 'startup' and 'shutdown' stuff just looks wrong.

[julian]

Very glad to see this. at $JOB we create an appliance and we have ami, azure and vmware versions and I can predict that google-compute is on the Horizon (actually it's already prototyped).
so I'm sure I will get to know and love (?) this port .. :-)

sysutils/py-google-compute-engine/files/google_accounts_daemon.in

21 ↗

(On Diff #32231)

at $JOB I have a similar situation with the AZURE startup scrpts. I default it to YES but the first thign it deos is check hw.vm_vendor (and a few other things) and return if it is not on azure. The aim is to have a single image that can run on all platforms. The thinking may be the same here. (or it may be just debugging)

sysutils/py-google-compute-engine/files/google_instance_setup.in

1 ↗

(On Diff #32231)

will these ever be run independently?

looks like you could combine several of these rc files into a single google_compute_support rc file

sysutils/py-google-compute-engine/files/google_shutdown_scripts.in

5 ↗

(On Diff #32231)

I Agree... Look at /etc/rc.shutdown

it calls all scripts with the # KEYWORD: shutdown entry, *in reverse order* with a shutdown argument

It's easier to keep track of things if the startup and shutdown are in the same file.

[ultima]

• Fixed items

[ultima]

sysutils/py-google-compute-engine/files/google_instance_setup.in

20 ↗

(On Diff #32231)

looks like I missed one.

[ultima]

Fixed items

[ultima]

sysutils/py-google-compute-engine/files/google_instance_setup.in

1 ↗

(On Diff #32231)

Probably so, however seeing as I have little knowledge on this software, better for the maintainer to answer, I suspect they will follow this differential as eager as they have been to get this in ports tree. If major changes are going to occur I'm going to pass this differential to them, assuming they are willing to use the tool.

[matthew]

Couple of spelling/grammar nits, but nothing that affects functionality.

lgtm.

sysutils/py-google-compute-engine/pkg-descr

1 ↗

(On Diff #32240)

grammar: 'which run in the'

sysutils/py-google-compute-engine/pkg-message

19 ↗

(On Diff #32240)

Typo: 'To enable the above services'