RunOperatorAsync breaks hosting lifecycle ?

[AndyPook]

As StartAsync is never called on the IHost, doesn't this mean that the dotnet Hosting model is ignored?

For examples:
if an IHostedService is added, it will never be started.
none of the IApplicationLifetime events are fired.
when the app stops none of the normal tidy up is executed.
etc

What if the contents of RunOperatorAsync were added to a BackgroundService? Which could be added via OperatorBuilder.AddOperatorBase.
Then no changes would be required to the normal Program template.

Something like:

    internal class OperatorHost : BackgroundService
    {
        private readonly IHostApplicationLifetime _hostApplicationLifetime;
        private readonly IServiceProvider _serviceProvider;

        public OperatorHost(IHostApplicationLifetime hostApplicationLifetime, IServiceProvider serviceProvider)
        {
            _hostApplicationLifetime = hostApplicationLifetime;
            _serviceProvider = serviceProvider;
        }

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            var args = Environment.GetCommandLineArgs();

            var app = new CommandLineApplication<RunOperator>();
            app
                .Conventions
                .UseDefaultConventions()
                .UseConstructorInjection(_serviceProvider);

            var exitCode = await app.ExecuteAsync(args);

            Environment.ExitCode = exitCode;
            _hostApplicationLifetime.StopApplication();
        }
    }

It is unfortunate that the command line args cannot be grabbed in a more elegant way 🙄

[erin-allison]

I think you are missing some of the fundamentals of how the CommandLineUtils package works, as IHost.RunAsync is definitely executed when using the templates defined in the documentation.

HostExtensions.RunOperatorAsync calls CommandLineApplication<RunOperator>.ExecuteAsync

https://github.com/buehler/dotnet-operator-sdk/blob/e5acde77b624db2e8a34c086451dd7f53cd3d05c/src/KubeOps/Operator/HostExtensions.cs#L21-L30

CommandLineApplication<T>.ExecuteAsync calls T.OnExecuteAsync and in this case, T is RunOperator

https://github.com/natemcmaster/CommandLineUtils/blob/1cb2c2455f677efe274c1cfc5e5dad91b9226ef0/src/CommandLineUtils/CommandLineApplication.cs#L854-L888

RunOperator.OnExecuteAsync is passed an IHost to its constructor and it calls IHost.RunAsync

https://github.com/buehler/dotnet-operator-sdk/blob/e5acde77b624db2e8a34c086451dd7f53cd3d05c/src/KubeOps/Operator/Commands/RunOperator.cs#L36-L50

Furthermore, there is no simple way that doing this in a background service could function, as the command line arguments are parsed and used to make decisions such as the namespace to register in and whether to wholly boot the application or just do basic setup to do things like generate CRDs.

[AndyPook]

I am familiar with CommandLineUtils. And had looked at the doc. Which is the reason I took a look as it looked "odd".
Just had not expected IHost to be injected for this purpose. (a little frustrated I didn't spot the RunAsync in RunOperator 😞 )
Somewhat unusual. But ok, sure, why not 😄

re: args... yes those are handled by the sample I gave. See Environment.GetCommandLineArgs().
But, as always, devils in the detail. (getting args this way would def make testing harder). It is frequently frustrating that Hosting does not make args more easily available.
It could take the values needed from IConfiguration? Then the settings could be "read" from other sources.

There are def ways of using Hosting extension points that would make Program more "normal". But little point, prob not worth the effort. (how many Operators is a team likely to create? a little fiddling in Program once per project.. 🤷 )

Anyway, thanks for taking the time to respond 🖖

[erin-allison]

re: args... yes those are handled by the sample I gave. See Environment.GetCommandLineArgs().

Indeed, the devil is in the details. I recognize your example handles command line arguments, but those aren't the issue as much as needing full control of the execution flow. If you were to try to work that into a background service such as you suggest, it would need to boot the whole application in order to simple generators such as for CRDs and other templates. If that is done, I don't see an easy way to guarantee the application doesn't take some form of action that could impact external systems.

In theory, EF Core 6 has shown us how it can be done without editing the entrypoint, but that involves shipping a tool binary which would just be more development time. Prior to .NET 6, though, it was similar in requiring a customized entrypoint by means of the public static CreateHostBuilder, so we're not alone in that regard.