Plugin Deployment: Config, logs, etc

Development
#1

As we begin to refine the installation of Katello as an engine with
Foreman, a couple of questions have arose with regards to what to do with
certain deployment artifacts for plugins in general. Those questions are:

  1. Should a plugin ever provide their own user? Should a plugin just rely
    on the foreman user and group?

  2. If a plugin needs to provide their own configuration, should that live
    in /etc/<plugin>/plugin.yml? Or something more like
    /etc/foreman/plugins/<plugin.yml>?
    /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more than
    just a yml file might be deployed as is the case with katello right now,
    deploying token and password files)

  3. Where should a plugin place any log files? For example, where should the
    katello installer place it's log file? Another example, Katello brings
    along delayed jobs which has its down production logs, should those live in
    /var/log/<plugin> or /var/log/foreman/ or /var/log/foreman/<plugin> ?

Those are a few of the clear examples, but I think you can see the general
trend of my questions and how this should apply across the board.

Thanks,
Eric

#2

> As we begin to refine the installation of Katello as an engine with
> Foreman, a couple of questions have arose with regards to what to do
> with certain deployment artifacts for plugins in general. Those
> questions are:
>
> 1. Should a plugin ever provide their own user? Should a plugin just
> rely on the foreman user and group?

To do what? The Rails app must run under a single UID, so are there
other tasks you'd implement under a second account?

> 2. If a plugin needs to provide their own configuration, should that
> live in /etc/<plugin>/plugin.yml? Or something more like
> /etc/foreman/plugins/<plugin.yml>?
> /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more
> than just a yml file might be deployed as is the case with katello right
> now, deploying token and password files)

I prefer /etc/foreman/plugins/<name>/*.

We have a low-level settings dir too that gets merged into
settings.yaml, under /usr/share/foreman/config/settings.plugins.d/, but
that's probably a different case.

> 3. Where should a plugin place any log files? For example, where should
> the katello installer place it's log file? Another example, Katello
> brings along delayed jobs which has its down production logs, should
> those live in /var/log/<plugin> or /var/log/foreman/ or
> /var/log/foreman/<plugin> ?

I'd mirror the confdir layout and do /var/log/foreman/<plugin>/.

··· On 24/01/14 14:38, Eric D Helms wrote:

–
Dominic Cleal
Red Hat Engineering

#3

> As we begin to refine the installation of Katello as an engine with
> Foreman, a couple of questions have arose with regards to what to do
> with certain deployment artifacts for plugins in general. Those
> questions are:
>
> 1. Should a plugin ever provide their own user? Should a plugin just
> rely on the foreman user and group?

since the plugins are all running under the foreman user, I'd vote for
relying on the foreman user.

>
> 2. If a plugin needs to provide their own configuration, should that
> live in /etc/<plugin>/plugin.yml? Or something more like
> /etc/foreman/plugins/<plugin.yml>?
> /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more
> than just a yml file might be deployed as is the case with katello right
> now, deploying token and password files)
>

since plugins are part of the Foreman application and can not run by
themselves they should live under foreman's config tree and I'd think
keeping things in their own directory is nice and tidy:

/etc/foreman/plugins/<plugin_name>

> 3. Where should a plugin place any log files? For example, where should
> the katello installer place it's log file? Another example, Katello
> brings along delayed jobs which has its down production logs, should
> those live in /var/log/<plugin> or /var/log/foreman/ or
> /var/log/foreman/<plugin> ?
>

/var/log/foreman/plugins/<plugin-name>

eg:

pwd

/var/log/foreman/plugins/katello/

ls

katello-install production_delayed_jobs_orch.log
production.log production_sql.log
production_delayed_jobs.log production_delayed_jobs_sql.log
production_orch.log

this is slightly different from what others said of just dumping them in:

/var/log/foreman/<plugin-name>

I think the 'plugins' subdir creates clarity on why the directory exists
even if it is one extra thing to have to search under.Those are a few of
the clear examples, but I think you can see the
> general trend of my questions and how this should apply across the board.

my general rule would be to think of plugins as being part of Foreman so
they should live underneath it with a clear indication that the files
are part of a plugin.

Mike

··· On 01/24/2014 06:38 AM, Eric D Helms wrote:

–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

#4

Hey,

> As we begin to refine the installation of Katello as an engine with
> Foreman, a couple of questions have arose with regards to what to do with
> certain deployment artifacts for plugins in general. Those questions are:
>
> 1. Should a plugin ever provide their own user? Should a plugin just rely
> on the foreman user and group?

Depends, you can rely I guess - foreman will be present for sure.

> 2. If a plugin needs to provide their own configuration, should that live
> in /etc/<plugin>/plugin.yml? Or something more like
> /etc/foreman/plugins/<plugin.yml>?
> /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more than
> just a yml file might be deployed as is the case with katello right now,
> deploying token and password files)

I like the plugin subdirectory.

> 3. Where should a plugin place any log files? For example, where should the
> katello installer place it's log file? Another example, Katello brings
> along delayed jobs which has its down production logs, should those live in
> /var/log/<plugin> or /var/log/foreman/ or /var/log/foreman/<plugin> ?

Ditto, we can configure other services to use subdirectory too, tight?

Additional questions (with answers!):

Plugins and i18n. We have implemented fully working i18n in
foreman_discovery plugin. I have made some changes in upstream projects,
so Foreman is now multidomain enabled. See the plugin to learn how this
works. Basically, no changes are necessary, except initialization i18n
code are required. There are rake tasks and a Makefile for extraction
and MO generation that work both for Foreman itself and plugins.

Note that only code strings currently work. Javascript and model names
(tables, columns) are currently not working (extraction will skip them).
This is still in TODO, JavaScript should be relatively easy, model
extraction is more challenging tho.

There is also foreman-debug script which is a bash rewrite of
katello-debug. It is much more simple, but it offers similar kind of
functionality as katello-debug. Consider using that for Foretello, I
could provide some easy way of extension (basically it foreman-debug
could just call sub-debug scripts or something like that and helper bash
functions which are used there could be extracted to be reused). This
way, we could have one single tarball for all required information + we
can now also upload tarballs to our own server.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

#5

> > As we begin to refine the installation of Katello as an engine with
> > Foreman, a couple of questions have arose with regards to what to do
> > with certain deployment artifacts for plugins in general. Those
> > questions are:
> >
> > 1. Should a plugin ever provide their own user? Should a plugin just
> > rely on the foreman user and group?
>
> To do what? The Rails app must run under a single UID, so are there
> other tasks you'd implement under a second account?
>

Not just services, I meant the question broadly across config files, log
files, certs, password files, etc. In the Katello case, at present, we
bring along the delayed jobs service for example which I think we currently
are running as the Foreman user. I am mostly looking for consensus and
caveats I may have missed where it would make sense to have your own user.
If there are none, then that makes this easy.

··· On Fri, Jan 24, 2014 at 9:42 AM, Dominic Cleal wrote: > On 24/01/14 14:38, Eric D Helms wrote:
  1. If a plugin needs to provide their own configuration, should that
    live in /etc//plugin.yml? Or something more like
    /etc/foreman/plugins/<plugin.yml>?
    /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more
    than just a yml file might be deployed as is the case with katello right
    now, deploying token and password files)

I prefer /etc/foreman/plugins//*.

We have a low-level settings dir too that gets merged into
settings.yaml, under /usr/share/foreman/config/settings.plugins.d/, but
that’s probably a different case.

  1. Where should a plugin place any log files? For example, where should
    the katello installer place it’s log file? Another example, Katello
    brings along delayed jobs which has its down production logs, should
    those live in /var/log/ or /var/log/foreman/ or
    /var/log/foreman/ ?

I’d mirror the confdir layout and do /var/log/foreman//.

–
Dominic Cleal
Red Hat Engineering

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

#6

> Hey,
>
> > As we begin to refine the installation of Katello as an engine with
> > Foreman, a couple of questions have arose with regards to what to do with
> > certain deployment artifacts for plugins in general. Those questions are:
> >
> > 1. Should a plugin ever provide their own user? Should a plugin just rely
> > on the foreman user and group?
>
> Depends, you can rely I guess - foreman will be present for sure.
>
> > 2. If a plugin needs to provide their own configuration, should that live
> > in /etc/<plugin>/plugin.yml? Or something more like
> > /etc/foreman/plugins/<plugin.yml>?
> > /etc/foreman/plguins/<plugin_name>/plugin.yml? (keeping in mind, more
> than
> > just a yml file might be deployed as is the case with katello right now,
> > deploying token and password files)
>
> I like the plugin subdirectory.
>

Would we rely on the Foreman RPM to establish these directories ?

E

··· On Mon, Jan 27, 2014 at 7:04 AM, Lukas Zapletal wrote:
  1. Where should a plugin place any log files? For example, where should
    the
    katello installer place it’s log file? Another example, Katello brings
    along delayed jobs which has its down production logs, should those live
    in
    /var/log/ or /var/log/foreman/ or /var/log/foreman/ ?

Ditto, we can configure other services to use subdirectory too, tight?

Additional questions (with answers!):

Plugins and i18n. We have implemented fully working i18n in
foreman_discovery plugin. I have made some changes in upstream projects,
so Foreman is now multidomain enabled. See the plugin to learn how this
works. Basically, no changes are necessary, except initialization i18n
code are required. There are rake tasks and a Makefile for extraction
and MO generation that work both for Foreman itself and plugins.

Note that only code strings currently work. Javascript and model names
(tables, columns) are currently not working (extraction will skip them).
This is still in TODO, JavaScript should be relatively easy, model
extraction is more challenging tho.

There is also foreman-debug script which is a bash rewrite of
katello-debug. It is much more simple, but it offers similar kind of
functionality as katello-debug. Consider using that for Foretello, I
could provide some easy way of extension (basically it foreman-debug
could just call sub-debug scripts or something like that and helper bash
functions which are used there could be extracted to be reused). This
way, we could have one single tarball for all required information + we
can now also upload tarballs to our own server.

–
Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

#7

> Would we rely on the Foreman RPM to establish these directories ?

Sure, if it's not there, raise a PR to create them. I assume every
plugin has Requires: foreman statement.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman