Re: [CentOS] RHEL changes

2021-01-25 Thread Ljubomir Ljubojevic
On 1/26/21 2:25 AM, Frank Cox wrote:
> On Tue, 26 Jan 2021 01:05:54 +
> Phil Perry wrote:
> 
>> Let me rephrase then. If you were installing Windows on that machine for 
>> your customer, who would 'own' the licence - you or your customer?
> 
> I'd have the customer buy it, just like I have the customer buy the hardware 
> today.
> 
> My usual practice is to give the customer a shopping list.  "Here's what you 
> need.  Let me know when you have one."  I don't do hardware at all.  Any 
> parts or repaired units that I pick up from the computer store are billed to 
> the customer, not to me.
> 

I have same business model. In my part of the world anything except
Windows is barely understood by general population, and trying t explain
overloads their minds and their eyes glaze over.
Since I can not provide VAT return/rebate for anything, I prepare the
list of hardware or even invoice for what needs to be bought and they
pay for it.

But even simple thing like buying space on Google account with
debit/credit card is too complicated for some so I ended up paying with
my card to get them more "Gmail space", and was unable to organize that
they replace my card with their card for several months, it took me 5
minutes of explaining so they understand why that is important.
So idea that customer will manage RHEL licenses is in my case ludicrous.

Since I manage clients PC's/networks for 20 years and I do not advertise
but get new clients via word of mouth, all clients just decide to trust
me and give me total control beside paying for what needs to be bought
on my recommendation without getting into details.

Only thing I can do to make Dev account theirs is to create separate
e-mail on their domain that I will have access to (I am guessing they
will forget it even exists in few months) so that Red Hat does not think
I own large number of systems. That is for those clients who actually
own domain...


-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] CentOS Dojo @FOSDEM, Next Week

2021-01-25 Thread Alain Reguera Delgado
On Mon, 2021-01-25 at 11:00 -0500, Rich Bowen wrote:
> Reminder: we will be holding our annual FOSDEM CentOS Dojo next
> weekon Thursday and Friday. It will of course be online. Details,
> schedule, and registration, are available at 
> https://wiki.centos.org/Events/Dojo/FOSDEM2021

Here is a promotional image for the date:

https://wiki.centos.org/Events/Dojo/FOSDEM2021?action=AttachFile=view=centos-fosdem-21.png

See you all there!

Best regards,
-- 
Alain Reguera Delgado 


signature.asc
Description: This is a digitally signed message part
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread Frank Cox
On Tue, 26 Jan 2021 01:05:54 +
Phil Perry wrote:

> Let me rephrase then. If you were installing Windows on that machine for 
> your customer, who would 'own' the licence - you or your customer?

I'd have the customer buy it, just like I have the customer buy the hardware 
today.

My usual practice is to give the customer a shopping list.  "Here's what you 
need.  Let me know when you have one."  I don't do hardware at all.  Any parts 
or repaired units that I pick up from the computer store are billed to the 
customer, not to me.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread Phil Perry

On 25/01/2021 20:47, Frank Cox wrote:

On Mon, 25 Jan 2021 20:17:17 +
Phil Perry wrote:


I'm assuming your customer has the relationship with Red Hat and
entitlement to 16 free copies, and you are their sub-contracted IT
professional responsible for installation and maintaining / supporting
that installation.


That's a big assumption to make.

I set up systems for businesses who want "a computer that does job x".  They don't know, 
care, or want to know what it runs on as long as the thing logs the production or makes the press 
crank on cue.  "Here's your appliance", and they throw it in a corner and maybe someone 
blows the dust off of it every couple of years when they're going by with a vacuum.

They don't want a relationship with Red Hat", and probably wouldn't even know 
what that is if I told them about it.

"Hey Frank, this thing just quit.  Make it work again."  That's all the 
involvement they want in the IT end of things.



Let me rephrase then. If you were installing Windows on that machine for 
your customer, who would 'own' the licence - you or your customer?


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS-virt] OS-level virtualization using LXC and systemd-nspawn containers

2021-01-25 Thread Scott Dowdle
Greetings,

- Original Message -
> OpenVZ 7 has no updates, and therefore is not suitable for
> production.

The free updates lag behind the paid Virtuozzo 7 version and plenty of people 
are using it in production.  I'm not one of those.

> LXC/LXD is the same technology, as I understand from
> linuxcontainers.org

linuxcontainers.org is owned by Canonical and yes it documents LXC... but LXD 
is a management layer on top of it which provides for easy clustering and even 
managing VMs.  I think it is the closest thing to vzctl/prlctl from OpenVZ.

> podman can't be a replacement for OpenVZ 6 / systemd-nspawn because
> it destroys the root filesystem on the container stop, and all
> changes made in container configs and other container files will be lost.
> This is a nightmare for the website hosting server with containers.

No, it does NOT destroy the delta disk (that's what I call where changes are 
stored) upon container stop and I'm not sure why you think it does.  You can 
even export a systemd unit file to manage the container as a systemd service or 
user service.  volumes are a nice way to handle persistence of data if you want 
to nuke the existing container and make a new one from scratch without losing 
your data.  While it is true you have to approach the container a little 
differently, podman systemd containers are fairly reasonable "system 
containers".
 
TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS-virt] OS-level virtualization using LXC and systemd-nspawn containers

2021-01-25 Thread Gena Makhomed

On 25.01.2021 22:24, Scott Dowdle wrote:


I found only two possible free/open source alternatives for OpenVZ 6:

- LXC
- systemd-nspawn



Some you seem to have overlooked?!?

1) OpenVZ 7
2) LXD from Canonical that is part of Ubuntu
3) podman containers with systemd installed (set /sbin/init as the entry point)


OpenVZ 7 has no updates, and therefore is not suitable for production.

LXC/LXD is the same technology, as I understand from linuxcontainers.org

podman can't be a replacement for OpenVZ 6 / systemd-nspawn because
it destroys the root filesystem on the container stop, and all changes
made in container configs and other container files will be lost.
This is a nightmare for the website hosting server with containers.

systemd-nspawn probably is the best fit for my tasks.
But systemd-nspawn also have some major disadvantages
in the current RHEL-stable and RHEL-beta versions:

https://bugzilla.redhat.com/show_bug.cgi?id=1913734

https://bugzilla.redhat.com/show_bug.cgi?id=1913806

Answering to your previous question:

> in the reproduction steps, disabling SELinux is a step?

SELinux must be disabled, because if SELinux is enabled
- it prevents systemd-nspawn containers from starting.

SELinux permissive mode is useless because it consumes
more resources compared to completely disabled SELinux.

--
Best regards,
 Gena
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS] RHEL changes

2021-01-25 Thread Frank Cox
On Mon, 25 Jan 2021 20:17:17 +
Phil Perry wrote:

> I'm assuming your customer has the relationship with Red Hat and 
> entitlement to 16 free copies, and you are their sub-contracted IT 
> professional responsible for installation and maintaining / supporting 
> that installation.

That's a big assumption to make.

I set up systems for businesses who want "a computer that does job x".  They 
don't know, care, or want to know what it runs on as long as the thing logs the 
production or makes the press crank on cue.  "Here's your appliance", and they 
throw it in a corner and maybe someone blows the dust off of it every couple of 
years when they're going by with a vacuum.

They don't want a relationship with Red Hat", and probably wouldn't even know 
what that is if I told them about it.

"Hey Frank, this thing just quit.  Make it work again."  That's all the 
involvement they want in the IT end of things.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS-virt] OS-level virtualization using LXC and systemd-nspawn containers

2021-01-25 Thread Scott Dowdle
Greetings,

- Original Message -
> I found only two possible free/open source alternatives for OpenVZ 6:
> 
> - LXC
> - systemd-nspawn

Some you seem to have overlooked?!?

1) OpenVZ 7
2) LXD from Canonical that is part of Ubuntu
3) podman containers with systemd installed (set /sbin/init as the entry point)

I use LXC on Proxmox VE (which I guess should be #4 above) some although I 
primarily use it for VMs.

Oh, LXD is supposedly packaged for other distros but given that they aren't 
much into SELinux and they are into snaps, I'd not really recommend it outside 
of Ubuntu.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS] RHEL changes

2021-01-25 Thread Phil Perry

On 25/01/2021 20:05, Marc Balmer via CentOS wrote:




Am 25.01.2021 um 17:04 schrieb Johnny Hughes :


I mean, I get it, some people are very upset with the new way CentOS is
being done.  And obviously people get to think what they think.  But
when this was announced, it was also announced that RHEL was going to be
opened up early in Q1 of 2021 (which has happened and is still happening).


So where is the option to install a RHEL system at a customer site, like I was
able with CentOS?



Unless I'm misunderstanding Red Hat's offer of 16 free licenses, I'm 
assuming you can install free RHEL for the customer, and that will form 
one of their (your customer's) 16 free entitlements. Unless your 
customer needs more than 16 free entitlements?


I'm assuming your customer has the relationship with Red Hat and 
entitlement to 16 free copies, and you are their sub-contracted IT 
professional responsible for installation and maintaining / supporting 
that installation.


Obviously if your customer requires in excess of 16 copies, this offer 
from Red Hat is not going to work for them, or you.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread John R. Dennison
On Mon, Jan 25, 2021 at 09:05:12PM +0100, Marc Balmer via CentOS wrote:
> 
> We suggested CentOS 8 to our customers.  And we have been badly f***ed 
> the a**.  Sorry for the wording that you may assume, but that is how it is.

Could you at least pretend to be professional when posting to our lists?

> Really, you (as in the CentOS project) totally screwed it.

Really, you, (as in you) totally don't get it.  *CentOS* didn't do this
thing; *Red Hat* did this thing.  Go blame them.





John
-- 
If there is an embarrassment equivalent of post-traumatic stress disorder,
South Carolina has it.

-- Dick Harpootlian, former state Democratic chairman, on its recent
   politics, New York Times, 12 June 2010


signature.asc
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread Marc Balmer via CentOS



> Am 25.01.2021 um 17:04 schrieb Johnny Hughes :
> 
> On 1/22/21 5:12 AM, Ljubomir Ljubojevic wrote:
>> On 1/22/21 9:29 AM, Marc Balmer via CentOS wrote:
 Hence it is as good as dead in my mind when looking into the future, I
 am looking for future distro of choice.
>>> 
>>> A little mentioned choice would be openSUSE, which is direction I am taking.
>> 
>> I do not like system where configuration app can overwrite manualy set
>> config. I started with ClarkConnect in 2005-2006 and to route public
>> subnet into my network I had to delete last iptables command then add my
>> own, but only after config system did it's own iptables commands. I had
>> to learn iptables before any other Linux commands and although I
>> mastered it, it is left in unpleasant memory (it took me weeks and help
>> from rare Linux admins to find a solution).
>> 
>> I did try SUSE around 2000 but it was complicated to do manual changes
>> (if it was not provided in YAST), so after ClarkConnect I had no desire
>> to even experiment with YAST.
>> 
>> 
> 
> I have no issues with OpenSUSE .. but how is OpenSUSE any better than
> CentOS Stream?

openSUSE is honest.

The CentOS project, RedHat, you, lied to us when you published CentOS 8
and claiming it would be supported until 2029.  We believed you because of
the good reputation you had built up with previous CentOS releases.

We suggested CentOS 8 to our customers.  And we have been badly f***ed 
the a**.  Sorry for the wording that you may assume, but that is how it is.

> It is not like we are rolling rawhide packages into CentOS Stream.  They
> are updating already created Enterprise Packages in current RHEL with
> Bug Fixes and Security Fixes and a small number of rebases (Enhamcments
> Fixes).  But the enhancements are not from Rawhide, they are rebases
> very close to the current releases.
> 
> Again .. absolutely nothing wrong with using OpenSUSE (or Ubuntu or
> Debian, etc).  I just do not see the advantage.

I see one big advantage:  These are honest projects, while you are liars.

> 
> I mean, I get it, some people are very upset with the new way CentOS is
> being done.  And obviously people get to think what they think.  But
> when this was announced, it was also announced that RHEL was going to be
> opened up early in Q1 of 2021 (which has happened and is still happening).

So where is the option to install a RHEL system at a customer site, like I was
able with CentOS?

Really, you (as in the CentOS project) totally screwed it.

> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS-virt] OS-level virtualization using LXC and systemd-nspawn containers

2021-01-25 Thread Gena Makhomed

Hello All,

OpenVZ 6 in the past was a very popular technology
for creating OS-level virtualization containers.

But OpenVZ 6 is EOL now (because RHEL 6 / CentOS 6 is EOL)
and all OpenVZ 6 users should migrate to some alternatives.

I found only two possible free/open source alternatives for OpenVZ 6:

- LXC
- systemd-nspawn

Does anyone use LXC and/or systemd-nspawn
containers on RHEL 8 / CentOS 8 for production?

What are advantages and disadvantages of each of these technologies?

Can you share your experience with LXC and/or systemd-nspawn
for RHEL 8 / CentOS 8 operating system on the hardware node?



As I understand, LXC is not supported by Red Hat and it should be used 
on RHEL at its own risk?


But, as I understand from the articles

- https://access.redhat.com/solutions/1533893
- https://access.redhat.com/articles/2726611

systemd-nspawn is also not supported by Red Hat and should be used at 
its own risk?


So, between LXC and systemd-nspawn is there no difference despite 
what systemd-nspawn is the part of the RHEL 8 operating system

and can be installed on the RHEL 8 from the BaseOS repo?

Are there any chances that the situation with support for systemd-nspawn
will change in the future and this OS-level virtualization technology
will become fully supported in the RHEL 8.x or the RHEL 9.x version?

--
Best regards,
 Gena

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt


Re: [CentOS-docs] Wiki Access for Cloud SiG

2021-01-25 Thread Akemi Yagi
On Mon, Jan 25, 2021 at 5:54 AM Amy Marrich  wrote:

> Akemi,
>
> The usernames for YatinKarel and JavierPena should be corrected now as
> well.
>
> Thanks for all your assistance,
>
> Amy
>
> *Amy Marrich*
>
> She/Her/Hers
>
> Principal Technical Marketing Manager - Cloud Platforms
>
> Red Hat, Inc 
>
> a...@redhat.com
>
> Mobile: 954-818-0514
>
> Slack:  amarrich
>
> IRC: spotz
> 
>
>
> On Sun, Jan 24, 2021 at 5:52 PM Akemi Yagi  wrote:
>
>> On Sun, Jan 24, 2021 at 1:12 PM Amy Marrich  wrote:
>>
>>> Ok updated to Camel Case - AmyMarrich. I'll let the others know as well.
>>>
>>> Thanks,
>>>
>>> Amy
>>>
>>> On Sun, Jan 24, 2021 at 1:22 PM Akemi Yagi  wrote:
>>>
 On Sat, Jan 23, 2021 at 2:38 PM Amy Marrich  wrote:

>
> On Fri, Jan 22, 2021 at 7:58 PM Akemi Yagi  wrote:
>
>> On Thu, Jan 21, 2021 at 11:50 AM Amy Marrich  wrote:
>>
>>> I'd like to request access to
>>> https://wiki.centos.org/SpecialInterestGroup/Cloud for the
>>> following people:
>>>
>>> amymarrich
>>> jpena
>>> AlfredoMoralejo
>>> yatinkarel
>>>
>>> Thanks,
>>>
>>> Amy
>>>
>>
>> AmyMarrich and AlfredoMoralejo should be able to edit the requested page.
>> Feel free to edit the homepage as well:
>>
>> https://wiki.centos.org/AmyMarrich
>> https://wiki.centos.org/AlfredoMoralejo
>>
>> Akemi
>>
>
OK, YatinKarel and JavierPena added and their homepages set up.

https://wiki.centos.org/JavierPena
https://wiki.centos.org/YatinKarel

Thank you,
Akemi
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs


Re: [CentOS] CentOS Stream suitability as a production webserver

2021-01-25 Thread Johnny Hughes
On 1/7/21 9:53 AM, Phil Perry wrote:
> On 07/01/2021 09:47, Jamie Burchell wrote:
>> Didn't the CentOS Vault repo ensure that every package ever published
>> was still available?
>>
> 
> Yes, it did, but that is not the intention for CentOS Stream moving
> forward. Only packages in CentOS Linux are moved to the vault at point
> release time. CentOS Stream only ever has the LATEST package version and
> nothing else.
> 
> There is a bug filed for this issue here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1908047
> 
> If it is likely to be an issue for you, please make that known. The more
> people this affects, the more likely it may be addressed.
> 
> 

This exists:

https://composes.centos.org/

I think at some point there is a plan to make builds from koji also
available, though we can't right nwo (only the production instance is
available and we can't open it to alld/l because of bandwidth).


>>> On 7 Jan 2021, at 07:03, Gordon Messmer 
>>> wrote:
>>>
>>> On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
 - No chance to "yum history undo last" as there are no older packages
>>>
>>>
>>> I've seen that mentioned as a change pretty frequently, but I don't
>>> think it is in any meaningful sense.
>>>
>>> In CentOS Stream, package versions may be rebased periodically, and
>>> the public repos will no longer have older packages to install when
>>> using "undo" or "rollback".
>>>
>>> In CentOS, package versions may be rebased at minor releases, and the
>>> public repos will no longer have older packages to install when using
>>> "undo" or "rollback".
>>>
>>> It's true that you might be able to roll back a simple patch in
>>> CentOS in between minor releases, but those are the updates that
>>> everyone seems to regard as being the safest, and least likely to
>>> cause problems, and therefore the least likely to need
>>> undo/rollback.  The only rational conclusion I can come to is that it
>>> doesn't matter if you're talking about CentOS today or Stream in the
>>> future: If you want to be able to roll back, you need a private
>>> mirror that keeps the package versions that you use.  If you don't
>>> want a mirror, then you need to build, test, and deploy complete
>>> images rather than making incremental changes to mutable systems. 
>>> None of this is new, it's always been this way and people have just
>>> accepted it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread Johnny Hughes
On 1/21/21 2:28 PM, Jamie Burchell wrote:
> The RHEL announcement is of no use to me or my company. We spin up 
> DigitalOcean droplets for each of our client websites/apps. If we were 
> utilising horizontal scaling we'd have even more droplets per website/app. 
> We'd easily have over 16 installations.
> 

Red Hat is working also with Hosting Providers to come up with plans.
If I were you, I would talk to the list at centos-questii...@redhat.com

I have no idea what the planned options are (I work on CentOS Linux 7
and 8 and CentOS Stream .. so I don't interact with that group.  This
initiative is one of their plans.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RHEL changes

2021-01-25 Thread Johnny Hughes
On 1/22/21 5:12 AM, Ljubomir Ljubojevic wrote:
> On 1/22/21 9:29 AM, Marc Balmer via CentOS wrote:
>>> Hence it is as good as dead in my mind when looking into the future, I
>>> am looking for future distro of choice.
>>
>> A little mentioned choice would be openSUSE, which is direction I am taking.
> 
> I do not like system where configuration app can overwrite manualy set
> config. I started with ClarkConnect in 2005-2006 and to route public
> subnet into my network I had to delete last iptables command then add my
> own, but only after config system did it's own iptables commands. I had
> to learn iptables before any other Linux commands and although I
> mastered it, it is left in unpleasant memory (it took me weeks and help
> from rare Linux admins to find a solution).
> 
> I did try SUSE around 2000 but it was complicated to do manual changes
> (if it was not provided in YAST), so after ClarkConnect I had no desire
> to even experiment with YAST.
> 
> 

I have no issues with OpenSUSE .. but how is OpenSUSE any better than
CentOS Stream?

It is not like we are rolling rawhide packages into CentOS Stream.  They
are updating already created Enterprise Packages in current RHEL with
Bug Fixes and Security Fixes and a small number of rebases (Enhamcments
Fixes).  But the enhancements are not from Rawhide, they are rebases
very close to the current releases.

Again .. absolutely nothing wrong with using OpenSUSE (or Ubuntu or
Debian, etc).  I just do not see the advantage.

I mean, I get it, some people are very upset with the new way CentOS is
being done.  And obviously people get to think what they think.  But
when this was announced, it was also announced that RHEL was going to be
opened up early in Q1 of 2021 (which has happened and is still happening).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Infiniband special ops?

2021-01-25 Thread Strahil Nikolov via CentOS
I have never played with Infinibad, but I think that those cards most
probably allow some checksum offloading capabilities.
Have you explored in that direction and test with checksum in ofloaded
mode ?

Best Regards,
Strahil Nikolov

В 15:49 + на 25.01.2021 (пн), lejeczek via CentOS написа:
> 
> On 22/01/2021 00:33, Steven Tardy wrote:
> > On Thu, Jan 21, 2021 at 6:34 PM lejeczek via CentOS 
> > mailto:centos@centos.org>> wrote:
> > 
> > Hi guys.
> > 
> > Hoping some net experts my stumble upon this message,
> > I have
> > an IPoIB direct host to host connection and:
> > 
> > -> $ ethtool ib1
> > Settings for ib1:
> >  Supported ports: [  ]
> >  Supported link modes:   Not reported
> >  Supported pause frame use: No
> >  Supports auto-negotiation: No
> >  Supported FEC modes: Not reported
> >  Advertised link modes:  Not reported
> >  Advertised pause frame use: No
> >  Advertised auto-negotiation: No
> >  Advertised FEC modes: Not reported
> >  Speed: 4Mb/s
> >  Duplex: Full
> >  Auto-negotiation: on
> >  Port: Other
> >  PHYAD: 255
> >  Transceiver: internal
> >  Link detected: yes
> > 
> > and that's both ends, both hosts, yet:
> > 
> >  > $ iperf3 -c 10.5.5.97
> > Connecting to host 10.5.5.97, port 5201
> > [  5] local 10.5.5.49 port 56874 connected to
> > 10.5.5.97 port
> > 5201
> > [ ID] Interval   Transfer Bitrate
> > Retr Cwnd
> > [  5]   0.00-1.00   sec  1.36 GBytes  11.6 Gbits/sec0
> > 2.50 MBytes
> > [  5]   1.00-2.00   sec  1.87 GBytes  16.0 Gbits/sec0
> > 2.50 MBytes
> > [  5]   2.00-3.00   sec  1.84 GBytes  15.8 Gbits/sec0
> > 2.50 MBytes
> > [  5]   3.00-4.00   sec  1.83 GBytes  15.7 Gbits/sec0
> > 2.50 MBytes
> > [  5]   4.00-5.00   sec  1.61 GBytes  13.9 Gbits/sec0
> > 2.50 MBytes
> > [  5]   5.00-6.00   sec  1.60 GBytes  13.8 Gbits/sec0
> > 2.50 MBytes
> > [  5]   6.00-7.00   sec  1.56 GBytes  13.4 Gbits/sec0
> > 2.50 MBytes
> > [  5]   7.00-8.00   sec  1.52 GBytes  13.1 Gbits/sec0
> > 2.50 MBytes
> > [  5]   8.00-9.00   sec  1.52 GBytes  13.1 Gbits/sec0
> > 2.50 MBytes
> > [  5]   9.00-10.00  sec  1.52 GBytes  13.1 Gbits/sec0
> > 2.50 MBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval   Transfer Bitrate Retr
> > [  5]   0.00-10.00  sec  16.2 GBytes  13.9 Gbits/sec
> > 0 sender
> > [  5]   0.00-10.00  sec  16.2 GBytes  13.9
> > Gbits/sec  receiver
> > 
> > It's rather an oldish platform which hosts the link,
> > PCIe is
> > only 2.0 but with link of x8 that should be able to carry
> > more than ~13Gbits/sec.
> > Infiniband is Mellanox's ConnectX-3.
> > 
> > Any thoughts on how to track the bottleneck or any
> > thoughts
> > 
> > 
> > 
> > Care to capture (a few seconds) of the *sender* side .pcap?
> > Often TCP receive window is too small or packet loss is to 
> > blame or round-trip-time.
> > All of these would be evident in the packet capture.
> > 
> > If you do multiple streams with the `-P 8` flag does that 
> > increase the throughput?
> > 
> > Google says these endpoints are 1.5ms apart:
> > 
> > (2.5 megabytes) / (13 Gbps) =
> > 1.53846154 milliseconds
> > 
> > 
> > 
> Seems that the platform in overall might not be enough. That 
> bitrate goes down even further when CPUs are fully loaded & 
> occupied.
> (I'll try to keep on investigating)
> 
> What I'm trying next is to have both ports(a dual-port card) 
> "teamed" by NM, with runner set to broadcast. I'm leaving 
> out "p-key" which NM sets to "default"(which is working with 
> a "regular" IPoIP connection)
> RHEL's "networking guide" docs say "...create a team from 
> two or more Wired or InfiniBand connections..."
> When I try to stand up such a team, master starts but 
> slaves, both, fail with:
> "...
>   [1611588576.8887] device (ib1): Activation: starting 
> connection 'team1055-slave-ib1' 
> (900d5073-366c-4a40-8c32-ac42c76f9c2e)
>   [1611588576.8889] device (ib1): state change: 
> disconnected -> prepare (reason 'none', sys-iface-state: 
> 'managed')
>   [1611588576.8973] device (ib1): state change: 
> prepare -> config (reason 'none', sys-iface-state: 'managed')
>   [1611588576.9199] device (ib1): state change: config 
> -> ip-config (reason 'none', sys-iface-state: 'managed')
>   [1611588576.9262] device (ib1): Activation: 
> connection 'team1055-slave-ib1' could not be enslaved
>   [1611588576.9272] device (ib1): state change: 
> ip-config -> failed (reason 'unknown', sys-iface-state: 
> 'managed')
>   [1611588576.9280] device (ib1): released from master 
> device nm-team
>   [1611589045.6268] device (ib1): carrier: link connected
> ..."
> 
> Any suggestions also 

[CentOS] CentOS Dojo @FOSDEM, Next Week

2021-01-25 Thread Rich Bowen
Reminder: we will be holding our annual FOSDEM CentOS Dojo next week on 
Thursday and Friday. It will of course be online. Details, schedule, and 
registration, are available at 
https://wiki.centos.org/Events/Dojo/FOSDEM2021  Registration is free.


Please come, and tel your colleagues!

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Infiniband special ops?

2021-01-25 Thread lejeczek via CentOS



On 22/01/2021 00:33, Steven Tardy wrote:
On Thu, Jan 21, 2021 at 6:34 PM lejeczek via CentOS 
mailto:centos@centos.org>> wrote:


Hi guys.

Hoping some net experts my stumble upon this message,
I have
an IPoIB direct host to host connection and:

-> $ ethtool ib1
Settings for ib1:
 Supported ports: [  ]
 Supported link modes:   Not reported
 Supported pause frame use: No
 Supports auto-negotiation: No
 Supported FEC modes: Not reported
 Advertised link modes:  Not reported
 Advertised pause frame use: No
 Advertised auto-negotiation: No
 Advertised FEC modes: Not reported
 Speed: 4Mb/s
 Duplex: Full
 Auto-negotiation: on
 Port: Other
 PHYAD: 255
 Transceiver: internal
 Link detected: yes

and that's both ends, both hosts, yet:

 > $ iperf3 -c 10.5.5.97
Connecting to host 10.5.5.97, port 5201
[  5] local 10.5.5.49 port 56874 connected to
10.5.5.97 port
5201
[ ID] Interval   Transfer Bitrate
Retr Cwnd
[  5]   0.00-1.00   sec  1.36 GBytes  11.6 Gbits/sec    0
2.50 MBytes
[  5]   1.00-2.00   sec  1.87 GBytes  16.0 Gbits/sec    0
2.50 MBytes
[  5]   2.00-3.00   sec  1.84 GBytes  15.8 Gbits/sec    0
2.50 MBytes
[  5]   3.00-4.00   sec  1.83 GBytes  15.7 Gbits/sec    0
2.50 MBytes
[  5]   4.00-5.00   sec  1.61 GBytes  13.9 Gbits/sec    0
2.50 MBytes
[  5]   5.00-6.00   sec  1.60 GBytes  13.8 Gbits/sec    0
2.50 MBytes
[  5]   6.00-7.00   sec  1.56 GBytes  13.4 Gbits/sec    0
2.50 MBytes
[  5]   7.00-8.00   sec  1.52 GBytes  13.1 Gbits/sec    0
2.50 MBytes
[  5]   8.00-9.00   sec  1.52 GBytes  13.1 Gbits/sec    0
2.50 MBytes
[  5]   9.00-10.00  sec  1.52 GBytes  13.1 Gbits/sec    0
2.50 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  16.2 GBytes  13.9 Gbits/sec
0 sender
[  5]   0.00-10.00  sec  16.2 GBytes  13.9
Gbits/sec  receiver

It's rather an oldish platform which hosts the link,
PCIe is
only 2.0 but with link of x8 that should be able to carry
more than ~13Gbits/sec.
Infiniband is Mellanox's ConnectX-3.

Any thoughts on how to track the bottleneck or any
thoughts



Care to capture (a few seconds) of the *sender* side .pcap?
Often TCP receive window is too small or packet loss is to 
blame or round-trip-time.

All of these would be evident in the packet capture.

If you do multiple streams with the `-P 8` flag does that 
increase the throughput?


Google says these endpoints are 1.5ms apart:

(2.5 megabytes) / (13 Gbps) =
1.53846154 milliseconds



Seems that the platform in overall might not be enough. That 
bitrate goes down even further when CPUs are fully loaded & 
occupied.

(I'll try to keep on investigating)

What I'm trying next is to have both ports(a dual-port card) 
"teamed" by NM, with runner set to broadcast. I'm leaving 
out "p-key" which NM sets to "default"(which is working with 
a "regular" IPoIP connection)
RHEL's "networking guide" docs say "...create a team from 
two or more Wired or InfiniBand connections..."
When I try to stand up such a team, master starts but 
slaves, both, fail with:

"...
  [1611588576.8887] device (ib1): Activation: starting 
connection 'team1055-slave-ib1' 
(900d5073-366c-4a40-8c32-ac42c76f9c2e)
  [1611588576.8889] device (ib1): state change: 
disconnected -> prepare (reason 'none', sys-iface-state: 
'managed')
  [1611588576.8973] device (ib1): state change: 
prepare -> config (reason 'none', sys-iface-state: 'managed')
  [1611588576.9199] device (ib1): state change: config 
-> ip-config (reason 'none', sys-iface-state: 'managed')
  [1611588576.9262] device (ib1): Activation: 
connection 'team1055-slave-ib1' could not be enslaved
  [1611588576.9272] device (ib1): state change: 
ip-config -> failed (reason 'unknown', sys-iface-state: 
'managed')
  [1611588576.9280] device (ib1): released from master 
device nm-team

  [1611589045.6268] device (ib1): carrier: link connected
..."

Any suggestions also appreciated.
thanks, L
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS-docs] Wiki Access for Cloud SiG

2021-01-25 Thread Amy Marrich
Akemi,

The usernames for YatinKarel and JavierPena should be corrected now as well.

Thanks for all your assistance,

Amy

*Amy Marrich*

She/Her/Hers

Principal Technical Marketing Manager - Cloud Platforms

Red Hat, Inc 

a...@redhat.com

Mobile: 954-818-0514

Slack:  amarrich

IRC: spotz



On Sun, Jan 24, 2021 at 5:52 PM Akemi Yagi  wrote:

> On Sun, Jan 24, 2021 at 1:12 PM Amy Marrich  wrote:
>
>> Ok updated to Camel Case - AmyMarrich. I'll let the others know as well.
>>
>> Thanks,
>>
>> Amy
>>
>> *Amy Marrich*
>>
>> She/Her/Hers
>>
>> Principal Technical Marketing Manager - Cloud Platforms
>>
>> Red Hat, Inc 
>>
>> a...@redhat.com
>>
>> Mobile: 954-818-0514
>>
>> Slack:  amarrich
>>
>> IRC: spotz
>> 
>>
>>
>> On Sun, Jan 24, 2021 at 1:22 PM Akemi Yagi  wrote:
>>
>>> On Sat, Jan 23, 2021 at 2:38 PM Amy Marrich  wrote:
>>>

 On Fri, Jan 22, 2021 at 7:58 PM Akemi Yagi  wrote:

> On Thu, Jan 21, 2021 at 11:50 AM Amy Marrich  wrote:
>
>> I'd like to request access to
>> https://wiki.centos.org/SpecialInterestGroup/Cloud for the following
>> people:
>>
>> amymarrich
>> jpena
>> AlfredoMoralejo
>> yatinkarel
>>
>> Thanks,
>>
>> Amy
>>
>
> AmyMarrich and AlfredoMoralejo should be able to edit the requested page.
> Feel free to edit the homepage as well:
>
> https://wiki.centos.org/AmyMarrich
> https://wiki.centos.org/AlfredoMoralejo
>
> Akemi
>
> ___
> CentOS-docs mailing list
> CentOS-docs@centos.org
> https://lists.centos.org/mailman/listinfo/centos-docs
>
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs


Re: [CentOS] RHEL changes

2021-01-25 Thread Thomas Bendler
On Thu, Jan 21, 2021 at 11:15 PM Nicolas Kovacs  wrote:

> Le 21/01/2021 à 22:17, Valeri Galtsev a écrit :
> > I tried Oracle Linux. After installation it took forever to update yum
> > database, or do you yum search. Also: I didn't find mirrors... All this
> sort of
> > ruled it out for me.
>
> Works perfectly here:
>
> https://gitlab.com/kikinovak/oracle/-/blob/master/linux-setup.sh
>
> You might want to give it another spin.
> [...]


Nice script but wouldn't it be easier to do such a thing with Ansible/
Puppet/ or
the like? You can refer in most cases to the RHEL family what would make it
work
on all flavours. You only have to adjust the parts with the specific URLs
...

Kind regards Thomas
-- 
Linux ... enjoy the ride!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos