goferd service fails due to katello-agent not being installed

[matthargrave]

The goferd service is created by the katello-agent package. This package should be installed if the service is managed. Attempting to add it to the package_names variable is not suitable because the system does not yet have the repos available, creating a circular dependency.

[waveclaw]

Access to the katello-agent package needs the agent to attach repositories with unknown and unpredictable names. So the service's package is not installed by this module.

The service dependency in the convenience class is an eventual configuration convergence step. When I designed that I expected there may be two or more Puppet runs required. This is reflected in the rhsm_repo_* facter facts and rhsm_repo types that require a second Puppet agent run to operate.

The Puppet admin for a site should know or be able to learn the source of the katello-agent package. At that point the admin can write Puppet DSL code to acquire the agent and activate the service in a single run.

1. Unset the subscription_manager::service_name in an override
2. Create a dependency between the success of rhsm_register and your specific repository containing the agent software
3. Add a resource to install the katello-agent package
4. Activate the goferd service yourself.

You can skip step one and four if you do not mind having the agent report a changed status on an extra report.

Or you can ensure that the system will have access to the package through default subscription configuration or other means. Then the agent will install and operate eventually.

[andrewfraley]

Is it possible to avoid applying subscription_manager::service? Everything you say above makes sense, but doing something like this:

class { 'subscription_manager':
  server_hostname => $server,
  org             => $org,
  activationkey   => $key,
  autosubscribe   => true,
  service_name    => Undef
}

generates an error in subscription_manager::service In service.pp, should the service definition be wrapped in an if statement instead?

if $::subscription_manager::service_name {
  service { $::subscription_manager::service_name:
    ensure     => $::subscription_manager::service_status,
    hasstatus  => true,
    hasrestart => true,
  }
}

[waveclaw]

I would not think so. You are exploring an advanced use case by preventing the service.

I would recommend rolling your own logic and using the parts from the module, like the native types, directly.

Sincerely,

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message -------- From: Andy Fraley notifications@github.com Date: 10/17/18 12:20 PM (GMT-07:00) To: waveclaw/puppet-subscription_manager puppet-subscription_manager@noreply.github.com Cc: JD Powell waveclaw@hotmail.com, Assign assign@noreply.github.com Subject: Re: [waveclaw/puppet-subscription_manager] goferd service fails due to katello-agent not being installed (#62)

Is it possible to avoid applying subscription_manager::service? Everything you say above makes sense, but doing something like this:

class { 'subscription_manager': server_hostname => $server, org => $org, activationkey => $key, autosubscribe => true, service_name => Undef }

generates an error in subscription_manager::service In service.pp, should the service definition be wrapped in an if statement instead?

if $::subscription_manager::service_name { service { $::subscription_manager::service_name: ensure => $::subscription_manager::service_status, hasstatus => true, hasrestart => true, } }

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/waveclaw/puppet-subscription_manager/issues/62#issuecomment-430735018, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAEf6fAhIKC6wfIodcn5IEbWEChncGbvks5ul3TmgaJpZM4SH2ic.

[waveclaw]

Experience with managing the katello-agent installation shows that this is best left as a separate explicit task for the admin to write. Baking the service-management logic into the module further would complicate the convenience logic while taking control away from the admin.

For those without need to directly manage the service I recommend that the katello-agent pacakge should appear in your subscribed repositories, e.g. katello-client or satellite-tools products imported into the service.