[Spacewalk-list] DIsk usage and limiting number of instances of a package

Fri May 11 09:00:20 UTC 2018

Hello folks, good morning

I'll check the code asap, but I would like to share some tricks. If you are
looking for some improvement, feel free to access the link [1] or just
access the project link [2] and then click on Issues tab, after that just
clock on New Issue and describe the problem. The owner of this project will
receive the request and all guys who will work with this code will be able
to help on this improvement.

Welcome to the opensource. :)

Another trick to claim storage is run vacuum on the postgres db just to
reorder the db and shrink when necessary. Basically when you sync some
repos, the data file *from DB* will increase, when you delete the data from
db, the data file still with the same size.

Best

[1]. https://github.com/00willo/spacewalk-scripts/issues
[2]. https://github.com/00willo/spacewalk-scripts
[3]. https://www.postgresql.org/docs/9.5/static/sql-vacuum.html

______________
Atenciosamente
Waldirio
msn: waldirio at gmail.com
Skype: waldirio
Site: www.waldirio.com.br
Blog: blog.waldirio.com.br
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646
PGP: www.waldirio.com.br/public.html

On Thu, May 10, 2018 at 12:54 PM, Dimitri Yioulos <dyioulos at netatlantic.com>
wrote:

> Make that decent J  .
>
>
>
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> *On Behalf Of *Dimitri Yioulos
> *Sent:* Thursday, May 10, 2018 3:53 PM
>
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] DIsk usage and limiting number of
> instances of a package
>
>
>
> Maybe a descent programmer (and I’m not that person) could modify the
> script to do what you ask.
>
>
>
> Dimitri
>
>
>
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> *On Behalf Of *Matthew Madey
> *Sent:* Thursday, May 10, 2018 3:17 PM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] DIsk usage and limiting number of
> instances of a package
>
>
>
> Is there any way this can be modified to keep "n" number of obsoleted
> packages?  I have a scenario where we need to do cleanup on developer
> packages.. they may have for instance 100 versions of a package. We need to
> keep a certain number of those packages around in case of a rollback
> scenario, but we want to clean up the rest.
>
>
>
> On Thu, May 10, 2018 at 12:47 PM, Dimitri Yioulos <
> dyioulos at netatlantic.com> wrote:
>
> Ah, sorry, I see that the script has been updated, and has some problems.
> I’ve pasted what I use here:  https://pastebin.com/8KuG6J5B .
>
>
>
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> *On Behalf Of *Dimitri Yioulos
> *Sent:* Thursday, May 10, 2018 1:10 PM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] DIsk usage and limiting number of
> instances of a package
>
>
>
> This works well for me:  https://github.com/00willo/
> spacewalk-scripts/blob/master/spacewalk-clean-old-packages.py .  I run it
> periodically via a cron job.
>
>
>
> Dimitri
>
>
>
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> *On Behalf Of *Mark Prangnell
> *Sent:* Thursday, May 10, 2018 11:57 AM
> *To:* spacewalk-list at redhat.com
> *Subject:* [Spacewalk-list] DIsk usage and limiting number of instances
> of a package
>
>
>
> Hi,
>
>
>
> I currently run a spacewalk server (v2.6) that is gradually using up all
> of its disk space.
>
>
>
> Currently have repositories for:
>
>
>
> 32 and 64bit CentOS 6 (and updates)
>
> CentOS 7 (and updates)
>
> Dell updates
>
> Backup software
>
>
>
> Also had (but have since removed) EPEL for CentOS 6 and 7 as I suspected
> these were the guilty party in terms of using up a chunk of disk space in
> the first place.
>
>
>
> Is there any way of limiting the amount of a instances of a specific
> package that are stored in a repository on spacewalk?
>
>
>
> Using kernel as an example, we have 21 revisions of it in one repository
> and probably only need the 5 most recent (if that). Would we need to
> manually remove them or is there some way of telling spacewalk to remove
> all but the latest 5 revisions of a package and delete the rest?
>
>
>
> Thanks,
>
> Mark
>
>
>
> ##############################################################################
> This communication together with any attachments transmitted with it ("this
> E-Mail") is intended only for the use of the addressee and may contain
> information which is privileged and confidential. If the reader of this
> E-Mail is not the intended recipient or the employee or agent responsible
> for delivering it to the intended recipient you are hereby notified that
> any use, dissemination, forwarding, printing or copying of this E-Mail is
> strictly prohibited. Addressees should check this E-mail for viruses. The
> Company makes no representations as regards the absence of viruses in this
> E-Mail. If you have received this E-Mail in error please notify our IT
> Service Desk immediately by e-mail at abuse.ttb at talktalkplc.com Please
> then immediately delete, erase or otherwise destroy this E-Mail and any
> copies of it. Any opinions expressed in this E-Mail are those of the author
> and do not necessarily constitute the views of the Company. Nothing in this
> E-Mail shall bind the Company in any contract or obligation. For the
> purposes of this E-Mail "the Company" means TalkTalk Telecom Group PLC
> and/or any of its subsidiaries. Please feel free to visit our website:
> www.talktalkgroup.com TalkTalk Telecom Group Plc (Registered in England &
> Wales No. 7105891) 11 Evesham Street, London W11 4AR
> ##############################################################################
>
>
> ############################################################
> ##################
> This communication together with any attachments transmitted with it
> ("this E-Mail") is intended only for the use of the addressee and may
> contain
> information which is privileged and confidential. If the reader of this
> E-Mail
> is not the intended recipient or the employee or agent responsible for
> delivering it to the intended recipient you are hereby notified that any
> use,
> dissemination, forwarding, printing or copying of this E-Mail is strictly
> prohibited. Addressees should check this E-mail for viruses. The Company
> makes
> no representations as regards the absence of viruses in this E-Mail. If you
> have received this E-Mail in error please notify our IT Service Desk
> immediately by e-mail at abuse.ttb at talktalkplc.com Please then immediately
> delete, erase or otherwise destroy this E-Mail and any copies of it.
>
> Any opinions expressed in this E-Mail are those of the author and do not
> necessarily constitute the views of the Company. Nothing in this E-Mail
> shall
> bind the Company in any contract or obligation.
>
> For the purposes of this E-Mail "the Company" means TalkTalk Telecom Group
> PLC
> and/or any of its subsidiaries.
>
> Please feel free to visit our website: www.talktalkgroup.com
>
> TalkTalk Telecom Group Plc (Registered in England & Wales No. 7105891)
> 11 Evesham Street, London W11 4AR
> ############################################################
> ##################
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20180511/7b295e44/attachment.htm>