Re: Freeze break request: moving /mnt/koji/compose/

2023-02-22 Thread Lubomír Sedlář 
Kevin Fenzi píše v St 22. 02. 2023 v 09:51 -0800:
> Greetings.
> 
> As some of you may know, our fedora_koji volume is hitting up against
> some limits (namely the netapp 100TB per volume limit). If it hits
> 100TB
> used, the netapp folks tell me it will go offline and we will need to
> do
> special things to free up any space and get it working again. 
> Obviously, we wish to avoid that. 
> 
> So, I think we can move /mnt/fedora_koji/koji/compose with minimal
> disruption and give us a bunch of room and actually make things
> faster.
> 
> Here's my tenative plan:
> 
> * create ~15-20TB volume on one of our ssd aggregates.
> * rsync all of /mnt/fedora_koji/koji/compose/ to it.
> * Schedule a changeover time/date.
> * Make sure no composes or updates pushes are running.
> (This should be possible after branched/rawhide, but before updates
> and before we are making rc's)
> * Do another sync of content so the new copy is up to date.
> (I am not sure how long a rsync will take, but we can figure it out)
> * move the old directory to compose.old
> * mount the new space on koji01/02, kojipkgs01/02, all compose
> channel
> builders, compose-x86-01. Nothing else should need it.
> * Wait a short while
> * delete compose.old
> 
> This should free up about 13TB or so on the main volume, reduce
> snapshot
> churn on it, make composes faster because they will be on ssd instead
> of
> sas drives, and all around be nicer.
> 
> I think this can be done during some day without really causing much
> outage. Because the koji space is so tight I would like to do it
> soon,
> and I think it best to do it before we are too close to release. 
> So, later this week or early next week?
> 
> Thoughts? +1s? alternative ideas?
> 

Hello,

are hardlinks taken into account the measurement?

In the current setup the composes are stored on the same volume that
Koji is using, right? That allows pungi to hardlink RPMs instead of
copying them around.

If the volumes are separate, it will have to copy the data over. This
should work automatically, but may negate some of the benefits of
having faster storage.

Lubomír

> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora and PDC

2018-06-08 Thread Lubomír Sedlář 
Pierre-Yves Chibon píše v Čt 07. 06. 2018 v 18:20 +0200:
> Good Morning Everyone,
> 
> So there has been a number of person who expressed in this topic.
> The list I have so far is:
> - Clime
> - bowlofeggs
> - cverna
> - nirik
> - lsedlar
> - abompard
> - cqi
> - Ken Dreyer
> - ralphbean
> - mboddu
> 
> I propose that we meet up next week on Monday at 14:00 UTC. 
> 
> 
> What do you prefer, IRC or video (bluejeans)?
> 
> 
> What do you all think?

The time works for me, and I have no preference over irc or bluejeans.

Lubomír
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/OP33GEBX2NQPZTREYSPOHPWSJHSEOKA2/

Re: Fedora and PDC

2018-04-23 Thread Lubomír Sedlář 
Hello,
please include me in the planning too. I happen to know Django and PDC
a bit, and want to help.

Lubomír

Pierre-Yves Chibon píše v Pá 20. 04. 2018 v 19:34 +0200:
> Good Morning Everyone,
> 
> We have been informed thst week at the upstream devs working on the
> product-definition-center (PDC) are moving away from the project and
> are going to leave it without a maintainer. Since we adopted PDC for
> a variety of data flows, this puts us in an awkward position. :(
> 
> Ralph and I met up on Tuesday to brainstorm the list of things we
> actively use PDC for today and to come up with a contingency plan for
> how to handle them. One overarching option is for us (fedora-infra)
> to take ownership of the PDC codebase as a whole. We didn't fully
> explore this option, figuring that the codebase is large and contains
> lots of tables, endpoints, and codepaths that we didn't use nor which
> we plan to use.
> 
> Instead, below we've got the four things we use PDC for and some
> options for what to do with each.
> 
> With the exception of /modules/, one common pattern that we like is
> to investigate splitting out the "django apps" that make up PDC into
> their own projects.  We're calling these "pdc-lite", for fun. See
> more below.
> 
> * Modules
> The data in the /modules/ PDC endpoint is *also* in the MBS
> db.  Ralph's team is going to just use that and stop using pdc
> anything for modules.
> We're going to need to patch pungi, mbs for local builds, and a
> few other places.  This should be a relatively low-pain transition.
> 
> * Stream branches, branch ownership, retirement dates?
> - SLA/EOL are currently stored in PDC.
> - Queried by releng scripts for retirement, fedrepo-req for new
> branches, etc..
> option #1
>   git repo full of yaml file similar to the override repo
>   compiled into a single JSON blob
>   Single place for all retired packages
>   This feels like the lowest tech option.
>   git gives us change control for free... but people easily get
> lost in the
>   "UX" of navigating a gigantic git repo full of plaintext files.
> option #2
>   pagure's DB/API
>   pagure knows nothing about branches currently, so that would be
> bigger
>   lift
> option #3
>   PDC internally is composed of ~20 "django apps"
>   https://github.com/product-definition-center/product-definition
> -center/tree/master/pdc/apps
>   We could pick the 2 or 3 that comprise the branches feature,
> copy them
>   out, and turn them into their own service: the "branch
> definition center":
>   BDC.
>   That would be the "pdc-lite" approach mentionned above, ie: PDC
> with only
>   the "app" of interest
> 
> * release/life-circle tracking?
> option #1:
>   PDC lite with just that app of interest
> option #2:
>   JSON/yaml file on the proxies
> option #3:
>   pkgdb-lite
> option #4:
>   ???
>   compose tracking?
> impacted: fedfind
> option #1:
>   PDC-lite with just that app of interest
> option #2:
>   Drop this entirely?
>   Adam probably really wants to keep the record of composes.
> option #3:
>   ???
> 
> The "pdc-lite" options are attractive, across the board.  One thing
> we get from this is greater clarity when discussing things formerly
> in PDC.  If something is in the branch-definition-center, the
> compose-definition-center, or the release-definition-center.. you
> know what you're talking about.  Today, when talking about whether or
> not something should be or is in "PDC", it is easy to get confused.
> 
> I propose we start the discussion on the list and plan for a meeting
> sometime late next week to discuss it further with the interested
> parties (please signal yourself)
> 
> 
> What do you think?
> 
> Pierre and Ralph
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.fedoraproj
> ect.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: FBR: Update pungi on branched-composer.phx2.fedoraproject.org and compose-x86-02.phx2.fedoraproject.org

2017-11-08 Thread Lubomír Sedlář 
This should not be strictly necessary. You can configure the target for
all live images with live_target option. E.g.:

live_target = 'some-name'

Lubomír

Mohan Boddu píše v St 08. 11. 2017 v 16:15 +:
> We need https://pagure.io/pungi/c/c89f0334579aee68286d07d4b57f4df6751
> 0166c?branch=master patch to create live images for arm in
> modularity, which is included in Pungi 4.1.20 release. So, I would
> like to update the branched composer and try it out. And if possible
> include it in F27 Beta Modular release based on time availability.
> 
> Thanks.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.fedoraproj
> ect.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

[PATCH] Add a cron job for rawhide nightly with DNF

2017-04-05 Thread Lubomír Sedlář 
In order to compare YUM and DNF compose, this will start a simplified
compose (no extra deliverables, just the packages) and create logs with
differences. The compose starts 12 hours after the real rawhide, which
should prevent any negative effects on the production compose (while
it's possible for the nightly to not finish yet, after 12 hours it would
only be waiting on koji tasks and not needed local resources much).

See https://pagure.io/pungi-fedora/pull-request/178 for details.

Signed-off-by: Lubomír Sedlář <lsed...@redhat.com>
---
 roles/releng/files/rawhide | 1 +
 1 file changed, 1 insertion(+)

diff --git a/roles/releng/files/rawhide b/roles/releng/files/rawhide
index bb72f76..62f4333 100644
--- a/roles/releng/files/rawhide
+++ b/roles/releng/files/rawhide
@@ -1,3 +1,4 @@
 # rawhide compose
 MAILTO=releng-c...@lists.fedoraproject.org
 15 5 * * * root TMPDIR=`mktemp -d /tmp/rawhide.XX` && cd $TMPDIR && git 
clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && LANG=en_US.UTF-8 
./nightly.sh && sudo -u ftpsync /usr/local/bin/update-fullfiletimelist -l 
/pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora 
fedora-secondary
+15 17 * * * root TPMDIR=$(mktemp -d /tmp/rawhide-dnf.XX) && cd $TMPDIR && 
git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && 
LANG=en_US.UTF-8 ./nightly-dnf.sh
-- 
2.9.3
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedorahosted and Trac

2016-09-08 Thread Lubomír Sedlář 
Stephen John Smoogen píše v Čt 08. 09. 2016 v 10:21 -0400:
> On 8 September 2016 at 09:54, Grant Gainey 
> wrote:
> > 
> > Hey folks,
> > 
> > Just saw the "Fedorahosted-sunset" announcement yesterday, and I
> > have a question/problem. The Spacewalk project moved its code to
> > github a while back, but https://fedorahosted.org/spacewalk/wiki is
> > still the primary source of info for the Spacewalk community.
> > Suggestions for what to do with/about our entire (large, heavily
> > used) Trac instance?
> > 
> 
> My initial thought would be the following:
> 
> I would look at taking the pages and importing them into the github
> as
> part of the project with the markup being markdown. I expect that
> users will find it less confusing than having to jump back and forth
> between sites to get items.
> 
> However that is just an initial thought which needs feedback also.

GitHub can provide a wiki for each project, so you could actually do
this and still have nice display on web. GitHub help has fairly good
page on cloning the wiki git repo:
https://help.github.com/articles/adding-and-editing-wiki-pages-locally/

> > 
> > Help?
> > 
> > Grant Gainey
> > --
> > Grant Gainey
> > Principal Software Engineer, Red Hat Satellite
> > ___
> > infrastructure mailing list
> > infrastructure@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/infrastruct...@lists.fe
> > doraproject.org
> 
> 
> 
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Fwd: fedmsg error log badges-backend01.phx2.fedoraproject.org

2016-09-07 Thread Lubomír Sedlář 
Pierre-Yves Chibon píše v St 07. 09. 2016 v 16:45 +0200:

> Looks like the logic used in fedbadges to process some of the pagure
> message is
> wrong.
> 

There is some information about the rule problems in this ticket:

https://fedorahosted.org/fedora-badges/ticket/434#comment:27

-- 
Lubomír Sedlář <lubomir.sed...@gmail.com>
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org