post

2020-10-06 Thread khadija khalki
hi Dear
my email is
laila.hajar.jan...@gmail.com
___
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


Mote - Issue Review, Management and Code Of Conduct

2020-10-06 Thread Akashdeep Dhar
Hi folks,

Mote (https://github.com/fedora-infra/mote/) was written in Flask so it can 
garner good advancements during the period of Hacktoberfest 2020 - should we 
have good issues and CODE_OF_CONDUCT.md and CONTRIBUTING.md which has gone 
through the attention of CPE. There are certain issues that I have made, which 
Justin has (thankfully) reviewed - we could use your help there.
1. Add CONTRIBUTING.md (https://github.com/fedora-infra/mote/issues/126)
2. Add CODE_OF_CONDUCT.md (https://github.com/fedora-infra/mote/issues/127)
3. Persist copyright footer information in mobile view 
(https://github.com/fedora-infra/mote/issues/128)
4. [Subjective] Redundant links on the top bar 
(https://github.com/fedora-infra/mote/issues/129)
5. [User experience] Underutilized top menu bar 
(https://github.com/fedora-infra/mote/issues/131)

I would be QAing the site and figuring out issues but an assistance to judge if 
at all the issue is worth solving would be appreciated. Also, if anyone has the 
admin rights on the repo and figures that the issue can be solved by person 
from outside the community - feel free to tag them with hacktoberfest label and 
set the topic of the repo as hacktoberfest.

Thanks and regards,
Akashdeep Dhar
t0xic0der
___
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


Fedora 33 Final Freeze now in effect!

2020-10-06 Thread Kevin Fenzi
Greetings.

we are now in the infrastructure freeze leading up to the Fedora 33
Final release. This is a final release freeze.

We do this to ensure that our infrastructure is stable and ready to
release Fedora 33 when it's available.

You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:

git clone
https://infrastructure.fedoraproject.org/infra/ansible.git
ansible/scripts/freezelist -i inventory

Any hosts listed as freezes is frozen until 2020-10-21 (or later if
release slips). Frozen hosts should have no changes made to them without
a sign-off on the change from at least 2 sysadmin-main or rel-eng
members, along with (in most cases) a patch of the exact change to be
made to this list.

Thanks,

kevin


signature.asc
Description: PGP signature
___
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


Re: Another Rust MirrorManager experiment

2020-10-06 Thread Stephen John Smoogen
On Tue, 6 Oct 2020 at 03:46, Adrian Reber  wrote:

> On Mon, Oct 05, 2020 at 08:30:12AM -0400, Stephen John Smoogen wrote:
> > On Mon, 5 Oct 2020 at 02:24, Adrian Reber  wrote:
> >
>
> > We are not wanting to deploy new EL7 systems but would probably install
> an
> > EL8 box for this. Does this change the need for moving to Fedora on it?
>
> I just asked on #fedora-rust, but it seems it is not easily possible to
> build the Fedora Rust packages for EL8. If I am understanding it
> correctly it seems we need to run the Rust based mirrorlist cache
> generation on a Fedora host. If we have a second mm-backend system
> (mm-backend02) that is Fedora based to generate the mirrorlist cache we
> could decrease the amount of RAM (32GB) on mm-backend01 to something
> like 8GB.
>
>
OK that makes sense. This will be something that needs upgrading every 6
months like our proxies, but it is what it is.



> Adrian
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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


Re: Another Rust MirrorManager experiment

2020-10-06 Thread Adrian Reber
On Mon, Oct 05, 2020 at 08:30:12AM -0400, Stephen John Smoogen wrote:
> On Mon, 5 Oct 2020 at 02:24, Adrian Reber  wrote:
> 
> > On Wed, Jul 01, 2020 at 09:16:05AM -0700, Kevin Fenzi wrote:
> > > On Tue, Jun 30, 2020 at 02:17:30PM +0200, Adrian Reber wrote:
> > > > On Mon, Jun 15, 2020 at 03:36:23PM -0700, Kevin Fenzi wrote:
> > > > > On Wed, Jun 10, 2020 at 11:09:49AM +0200, Adrian Reber wrote:
> > > > > >
> > > > > > Then I just have to wait a bit. No problem.
> > > > > >
> > > > > > > > Having the possibility to generate the mirrorlist input data
> > in about a
> > > > > > > > minute would significantly reduce the load on the database
> > server and
> > > > > > > > enable us to react much faster if broken protobuf data has
> > been synced
> > > > > > > > to the mirrorlist servers on the proxies.
> > > > > > >
> > > > > > > Yeah, and I wonder if it would let us revisit the entire
> > sequence from
> > > > > > > 'update push finished' to updated mirrorlist server.
> > > > >
> > > > > This would help us with the case of:
> > > > > - updates push/rawhide finishes, master mirror is updated.
> > > > > - openqa/other internal thing tries to get images or updates in that
> > > > >   change and gets a metalink with the old checksum so it can't get
> > the
> > > > >   new stuff.
> > > > > - mm-backend01 generates and pushes out a new protobuf.
> > > > > >
> > > > > > Probably. As the new code will not run on the current RHEL 7 based
> > > > > > mm-backend01 would it make sense to run a short running service
> > like
> > > > > > this on Fedora's OpenShift? We could also create a new read-only
> > (SELECT
> > > > > > only) database account for this.
> > > > >
> > > > > We could, or as smooge suggests make a mm-backend02?
> > > > >
> > > > > But I guess now mm-backend02 just generates new proobuf files and
> > copies
> > > > > them to mirrorlists? If thats all it's doing, perhaps we could indeed
> > > > > replace it with an openshift project.
> > > >
> > > > We need a system to run the tool and copy the data to all proxies.
> > > >
> > > > I would like to see a new MirrorManager database user who can only do
> > > > selects as that is all we need.
> > > >
> > > > Currently we copy the files via SSH to the proxies, if we continue
> > doing
> > > > it that way, then we would also need the existing SSH key to copy the
> > > > data to the proxies.
> > > >
> > > > Easiest would probably be a small Fedora 32 based VM with 2GB of
> > memory.
> > >
> > > I'm not sure f32 will work with 2gb memory anymore. I dont think it
> > > installs at any rate.
> > >
> > > I do like the idea of just making it an openshift pod. Perhaps this
> > > could even fit with pingous 'toddlers' setup. ie:
> >
> > I tried to create a toddler, but that setup is too complicated for me.
> > Especially if something is not working it will be almost impossible for
> > me to debug it if it is running somewhere I cannot reach via SSH.
> >
> > I just tried to build the generate-mirrorlist-cache on RHEL 7 (using
> > Rust from EPEL) and it works fine. Instead of 20 minutes it needs 30
> > seconds to generate the mirrorlist cache file on mm-backend01.
> >
> > Although a RPM is available in Fedora I am not sure the RPM can be made
> > available in EPEL 7.
> >
> > RPM Fusion is using the Rust based generate-mirrorlist-cache for some
> > months already and I do not see any problems with it.
> >
> >
> We are not wanting to deploy new EL7 systems but would probably install an
> EL8 box for this. Does this change the need for moving to Fedora on it?

I just asked on #fedora-rust, but it seems it is not easily possible to
build the Fedora Rust packages for EL8. If I am understanding it
correctly it seems we need to run the Rust based mirrorlist cache
generation on a Fedora host. If we have a second mm-backend system
(mm-backend02) that is Fedora based to generate the mirrorlist cache we
could decrease the amount of RAM (32GB) on mm-backend01 to something
like 8GB.

Adrian


signature.asc
Description: PGP signature
___
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