7:05 a.m.
Hello,
there is new sysvinit script katello-jobs in the Katello release
0.1.66-1. Keep this service up and running from now on, otherwise your
CLI or UI can hang!
For more info see: https://fedorahosted.org/katello/wiki/KatelloJobs
== Service katello-jobs ==
The service is for executing background processes (synchronizations,
promotions). If the service is not running, katello CLI and UI could
possibly hang.
=== How to start it ===
{{{
service katello-jobs start
}}}
=== How to configure it ===
See the {{{/etc/sysconfig/katello}}} configuration file:
{{{
# number of katello-job service background workers
#KATELLO_JOB_WORKERS=1
# additional katello-job service options for delayed_jobs
#KATELLO_JOB_WORKERS=-m -p katello
}}}
=== How to monitor it ===
See the {{{/var/log/katello/}}} directory:
* jobs-startup.log -- startup daemon messages
* production_delayed_jobs.log -- individual logs from workers
Installation wiki page has been updated as well.
--
Later,
Lukas "lzap" Zapletal
11:02 a.m.
On Fri, 2011-08-19 at 14:05 +0200, Lukas Zapletal wrote:
Hello,
there is new sysvinit script katello-jobs in the Katello release
0.1.66-1. Keep this service up and running from now on, otherwise your
CLI or UI can hang!
For more info see: https://fedorahosted.org/katello/wiki/KatelloJobs
== Service katello-jobs ==
The service is for executing background processes (synchronizations,
promotions). If the service is not running, katello CLI and UI could
possibly hang.
=== How to start it ===
{{{
service katello-jobs start
}}}
=== How to configure it ===
See the {{{/etc/sysconfig/katello}}} configuration file:
{{{
# number of katello-job service background workers
#KATELLO_JOB_WORKERS=1
# additional katello-job service options for delayed_jobs
#KATELLO_JOB_WORKERS=-m -p katello
}}}
=== How to monitor it ===
See the {{{/var/log/katello/}}} directory:
* jobs-startup.log -- startup daemon messages
* production_delayed_jobs.log -- individual logs from workers
Installation wiki page has been updated as well.
Lukas,
I assume that the init script for katello was modified so that it calls
katello-jobs as well? If not, I think it should.
--
Jeff Weiss
Senior Quality Assurance Engineer
jweiss(a)redhat.com
(919)754-4178
3:55 p.m.
On 08/22/2011 10:02 AM, Jeff Weiss wrote:
On Fri, 2011-08-19 at 14:05 +0200, Lukas Zapletal wrote:
> Hello,
>
> there is new sysvinit script katello-jobs in the Katello release
> 0.1.66-1. Keep this service up and running from now on, otherwise your
> CLI or UI can hang!
>
> For more info see: https://fedorahosted.org/katello/wiki/KatelloJobs
>
> == Service katello-jobs ==
>
> The service is for executing background processes (synchronizations,
> promotions). If the service is not running, katello CLI and UI could
> possibly hang.
>
> === How to start it ===
>
> {{{
> service katello-jobs start
> }}}
>
> === How to configure it ===
>
> See the {{{/etc/sysconfig/katello}}} configuration file:
>
> {{{
> # number of katello-job service background workers
> #KATELLO_JOB_WORKERS=1
>
> # additional katello-job service options for delayed_jobs
> #KATELLO_JOB_WORKERS=-m -p katello
> }}}
>
> === How to monitor it ===
>
> See the {{{/var/log/katello/}}} directory:
>
> * jobs-startup.log -- startup daemon messages
> * production_delayed_jobs.log -- individual logs from workers
>
> Installation wiki page has been updated as well.
>
Lukas,
I assume that the init script for katello was modified so that it calls
katello-jobs as well? If not, I think it should.
+1
-J
--
Jason E. Rist
Senior Software Engineer
Systems Management and Cloud Enablement
Red Hat, Inc.
+1.919.754.4048
Freenode: jrist
1:58 a.m.
On 08/22/2011 11:55 PM, Jason Rist wrote:
On 08/22/2011 10:02 AM, Jeff Weiss wrote:
> On Fri, 2011-08-19 at 14:05 +0200, Lukas Zapletal wrote:
>> Hello,
>>
>> there is new sysvinit script katello-jobs in the Katello release
>> 0.1.66-1. Keep this service up and running from now on, otherwise your
>> CLI or UI can hang!
>>
>> For more info see: https://fedorahosted.org/katello/wiki/KatelloJobs
>>
>> == Service katello-jobs ==
>>
>> The service is for executing background processes (synchronizations,
>> promotions). If the service is not running, katello CLI and UI could
>> possibly hang.
>>
>> === How to start it ===
>>
>> {{{
>> service katello-jobs start
>> }}}
>>
>> === How to configure it ===
>>
>> See the {{{/etc/sysconfig/katello}}} configuration file:
>>
>> {{{
>> # number of katello-job service background workers
>> #KATELLO_JOB_WORKERS=1
>>
>> # additional katello-job service options for delayed_jobs
>> #KATELLO_JOB_WORKERS=-m -p katello
>> }}}
>>
>> === How to monitor it ===
>>
>> See the {{{/var/log/katello/}}} directory:
>>
>> * jobs-startup.log -- startup daemon messages
>> * production_delayed_jobs.log -- individual logs from workers
>>
>> Installation wiki page has been updated as well.
>>
> Lukas,
>
> I assume that the init script for katello was modified so that it calls
> katello-jobs as well? If not, I think it should.
>
>
+1
-J
IMHO it should be a separate service, as we are planning to switch to
apache/thin (there would be no katello startup script anymroe).
Ohad
4:59 a.m.
On 08/23/2011 08:58 AM, Ohad Levy wrote:
IMHO it should be a separate service, as we are planning to switch
to
apache/thin (there would be no katello startup script anymroe).
Yeah the plan is:
- As a dev, I'd like to migrate to apache2/thin
- change the application root url (/katello)
- As a user, I'd like to have katello super init script
- move initdb and depcheck out of katello init script
- new super init script "katello" (starts apache, thin and jobs)
- similar to pulp-server init script
In any case we should allow user possibility to deploy it on different
box. Since repo syncing and other long-running processes can be really
time/resource consuming, users could run it on a separate box.
I did not want to confuse users and start start katello-jobs from
katello service itself. Rather than creating one new script (katello,
katello-server and katello-jobs) I decided to postpone this after we
migrate to thin.
The installation documentation is up-to-date. I hope we will switch soon.
--
Later,
Lukas "lzap" Zapletal
6:49 a.m.
On 08/23/2011 12:59 PM, Lukas Zapletal wrote:
On 08/23/2011 08:58 AM, Ohad Levy wrote:
> IMHO it should be a separate service, as we are planning to switch to
> apache/thin (there would be no katello startup script anymroe).
Yeah the plan is:
- As a dev, I'd like to migrate to apache2/thin
- change the application root url (/katello)
- As a user, I'd like to have katello super init script
- move initdb and depcheck out of katello init script
- new super init script "katello" (starts apache, thin and jobs)
- similar to pulp-server init script
In any case we should allow user possibility to deploy it on different
box. Since repo syncing and other long-running processes can be really
time/resource consuming, users could run it on a separate box.
I did not want to confuse users and start start katello-jobs from
katello service itself. Rather than creating one new script (katello,
katello-server and katello-jobs) I decided to postpone this after we
migrate to thin.
The installation documentation is up-to-date. I hope we will switch soon.
From a managed system perspective, imho, each service should activate
only itself.
this becomes a real issue if you share a daemon across applications
(such as apache, or a database).
we currently have the scenario, that upon pulp restart, it also restarts
apache and mongo, what if we run katello on the same box?
from puppet point of view, each service must be managed one time,
otherwise you get unexpected results (service gets restarted at the
wrong time for example).
my two cents.
Ohad
7:36 a.m.
On 08/23/2011 01:49 PM, Ohad Levy wrote:
From a managed system perspective, imho, each service should
activate
only itself.
this becomes a real issue if you share a daemon across applications
(such as apache, or a database).
we currently have the scenario, that upon pulp restart, it also restarts
apache and mongo, what if we run katello on the same box?
from puppet point of view, each service must be managed one time,
otherwise you get unexpected results (service gets restarted at the
wrong time for example).
my two cents.
That's true and I agree with that.
But I checked Fedora Packaging Guidelines and there is no prohibition of
doing that. Then I asked Fedora devs and they told me you *should not*
do it, but its not prohibited.
The preferred way of starting dependant services is via LSB header (for
sysvinit scripts). Systemd can intepret that. I am not sure how this
works without systemd.
Yeah, Pulp team does the same with their pulp-server script. But this
does not mean it is correct :-) Let's open that topic on the pulp list.
--
Later,
Lukas "lzap" Zapletal
8:41 a.m.
On Tue, 2011-08-23 at 14:36 +0200, Lukas Zapletal wrote:
On 08/23/2011 01:49 PM, Ohad Levy wrote:
> From a managed system perspective, imho, each service should activate
> only itself.
> this becomes a real issue if you share a daemon across applications
> (such as apache, or a database).
>
> we currently have the scenario, that upon pulp restart, it also restarts
> apache and mongo, what if we run katello on the same box?
> from puppet point of view, each service must be managed one time,
> otherwise you get unexpected results (service gets restarted at the
> wrong time for example).
>
> my two cents.
That's true and I agree with that.
But I checked Fedora Packaging Guidelines and there is no prohibition of
doing that. Then I asked Fedora devs and they told me you *should not*
do it, but its not prohibited.
The preferred way of starting dependant services is via LSB header (for
sysvinit scripts). Systemd can intepret that. I am not sure how this
works without systemd.
Yeah, Pulp team does the same with their pulp-server script. But this
does not mean it is correct :-) Let's open that topic on the pulp list.
That's a good point, that having a service script start its own
dependency services is probably not a good idea.
However, what about just checking that the dependencies are there and
returning nonzero error code if they are not (along with a message
stating that)?
Jeff
9:02 a.m.
On 08/23/2011 04:41 PM, Jeff Weiss wrote:
On Tue, 2011-08-23 at 14:36 +0200, Lukas Zapletal wrote:
> On 08/23/2011 01:49 PM, Ohad Levy wrote:
>> From a managed system perspective, imho, each service should activate
>> only itself.
>> this becomes a real issue if you share a daemon across applications
>> (such as apache, or a database).
>>
>> we currently have the scenario, that upon pulp restart, it also restarts
>> apache and mongo, what if we run katello on the same box?
>> from puppet point of view, each service must be managed one time,
>> otherwise you get unexpected results (service gets restarted at the
>> wrong time for example).
>>
>> my two cents.
> That's true and I agree with that.
>
> But I checked Fedora Packaging Guidelines and there is no prohibition of
> doing that. Then I asked Fedora devs and they told me you *should not*
> do it, but its not prohibited.
>
> The preferred way of starting dependant services is via LSB header (for
> sysvinit scripts). Systemd can intepret that. I am not sure how this
> works without systemd.
>
> Yeah, Pulp team does the same with their pulp-server script. But this
> does not mean it is correct :-) Let's open that topic on the pulp list.
>
That's a good point, that having a service script start its own
dependency services is probably not a good idea.
However, what about just checking that the dependencies are there and
returning nonzero error code if they are not (along with a message
stating that)?
+1
nevertheless, the lsb headers should take care fore that (and of course
in our puppet manifests).
Ohad
Jeff
_______________________________________________
katello mailing list
katello(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/katello
9:52 a.m.
On 08/23/2011 04:02 PM, Ohad Levy wrote:
> However, what about just checking that the dependencies are there
and
> > returning nonzero error code if they are not (along with a message
> > stating that)?
+1
I am also for going the pulp-server way. At least for now-
Frankly I did not even started studying systemd yet. But I plan to do...
--
Later,
Lukas "lzap" Zapletal
10 a.m.
On 08/23/2011 05:52 PM, Lukas Zapletal wrote:
On 08/23/2011 04:02 PM, Ohad Levy wrote:
>> However, what about just checking that the dependencies are there and
>>> returning nonzero error code if they are not (along with a message
>>> stating that)?
> +1
I am also for going the pulp-server way. At least for now-
big -1 from my side...
we should not start any other service, rather
provide a simple installation procedure which takes care for the small
details.
Ohad
Frankly I did not even started studying systemd yet. But I plan to
do...
4637
days inactive
4641
days old
katello@lists.fedorahosted.org
10 comments
4 participants
participants (4)
-
Jason Rist -
Jeff Weiss -
Lukas Zapletal -
Ohad Levy