วีดีโอ

I don't believe that would work, but if you find a way I highly doubt it would be supported.

I am glad you liked it.

It should be configured on the routable network. It won't work in the air-gapped or disconnected mode. When the nodes boot up you should be able to console in and verify if there are any connectivity issues.

@@TrustedAdvisor-chrisj Thanks, so it means the BareMEtal hosts should have a routable network towards the internet somehow.

@@JoaoMouta-d5b - you don't need the internet public IPs if that is what you are illuding to. But the BMs need to be connected to the internet.

Glad it was helpful!

Glad you enjoyed it

Also when can we expect the next video on Mcvlan, sriov, host device networks ?

Thanks for your comment! I have included the reference to NADs and NNCPs in the video description. I don't know if I'll create a dedicated video for that. Let me know your questions and I'll try to answer them here. As for the macvlan, sriov and host device networks video - it might be a while - I have some other videos in the pipeline at the moment. Unfortunately, I can only do these videos in my spare time and I haven't had much of that recently with all the interest in OpenShift I have been swamped in my daytime job.

Sorry to hear that. It's not an easy topic. It was not a hard video to make, since there are just so many details. Thanks for your feedback.

This is just for the access to bmc network - think idrac, ilo, etc. Your installer would use that mostly for the power management of the physical boxes. It's typically handled by a hardware switch/router.

@@chrisitguy Thank you for your reply! The outer router connected to the API VIP and Ingress VIP seems to me like a HAProxy or a similar load balancer. The internal router connected to the control plane and worker nodes, on the other hand, seems more like a CNI component such as OVN, OpenShift SDN, or Calico, managing the internal cluster networking.

@@itlearner1175 - Technically you could connect API and Ingress traffic with something like external HAproxy - checkout the "Distributed Architecture" video for details. If you are using standard deployment though there is still HAproxy and keepalive components running on the OCP cluster itself. The other (optional) router is there to just handle the hardware management.

Thanks for your comment. It's on my to-do list, although the videos is just my side gig. I am working on them in between my daytime job.

The ip address gets injected during installation. You can find out the mac address from the hardware console.

The video shows deployment on Baremetal. It will use whatever is being provided

@@TrustedAdvisor-chrisj Would you suggest any economical service to rent severs for home lab please?

Not really. It's probably the cheapest to buy a single PC with good cpu and a lot of ram and just run it in virtual machines. Don't expect any good performance

Glad it was helpful!

If you do it for the first time or have a single cluster, then Assited. My favorite is agent based installer though

@@ramkarri2742 thanks. I am glad it's been helpful

I haven't dived deep into where they get pulled from, but they end up getting stored on a small http server running in the openstack namespace pod

I have been running on rather old Lenovo systemX servers and some BNT switches for the longest time. I just recently got a new R660s from Dell with very nice SonicOS switches.

Glad it was helpful!

it could be many things .. I'd say it's probably best to open a support case with Red Hat and let them guide you though the troubleshooting - support.redhat.com

Thanks for your comment. This video has been a biggest rabbit hole I have worked on so far. It's so easy to get into details that could mud the big picture. There is a reason why it ended up being the longest video I have done. I'd love to go into network flows, however I don't foresee it happening soon. I have some other cool networking topics to cover first .. like BGP integration (current and upcoming) and bunch of other stuff.

@@TrustedAdvisor-chrisj Wait for BGP integration topic. Thanks!

thanks. I am thinking of making MetalLB BGP dedicated video and the full Openshift FRR stuff once it gets released.

So nice of you

I appreciate it!

Hi @ssaa3209. Thanks for your comment. Setting platform to None is supported, however it does come with some small tradeoffs not described in this video like no machine-api or disabled metal3. The second one can be added just fine day2. I think it's totally worth it .. I have been running this architecture for few months with very little sacrifices. One lessons learned is to not create MCP for each AZs unless you are running a large cluster. It's not best fit for everything. I generally still use a mix of distributed and regular clusters that are running in the same layer2 and then abstract them with something like ArgoCD or ACM. There is pros and cons to everything. As of ironic LB, I have created it but it's not even used in my deployment. There is a very niche use case for this. Not even RHOSO would use that as far as I can tell. Just disregard it and sorry for confusion.

@@TrustedAdvisor-chrisj PLease Can you share the Full used Install-config.yaml file as well as the agent-config.yaml just to make sure that i have all the populated settings correct !!!!, another question in another situation if i need to segregate the LB between the HA LB and the KeepAlived can i do it and in this case what is the Config inside the install-config.yaml ??? how it will be Entered !!!!!!!!

I have just added the config into the description of the video. With the external LoadBalancer you will no longer need Keepalived

@@TrustedAdvisor-chrisj sorry for rebounding but how the Cluster will know about the IP's of the API and Ingress VIP, in the install-config only user managed but no further info !!! is that enough ?? appreciate your response

There is really no need for injecting those 2 VIPs into install-config. Just ensure your DNS A records are in place and that you LB can properly direct traffic to controllers for the API traffic and your workers/computes for the Ingress Controller traffic. The included yaml files worked for me.

Here is a cool video for my good friend Leif for showing some POC around this -> th-cam.com/video/NhAn1m9JHLo/w-d-xo.html .. I'd love to make a video myself around it, but there is at least few more other ideas that I'd like to record first. Thanks for your comment.

Every software is locking you in, but OpenShift I'd argue to a lesser degree. You could move to other Kubernetes distribution relatively easy. Also there is a OKD option if you decide to not pay a vendor for support. Thanks for your comment.

OKD? BTW, one can simply use upstream k8s. Works like a charm on metal.

@fio_mak OKD is an upstream, unpaid version of Openshift. No vendor support, though, just like a plain K8s. Going with the upstream Kubernetes is just fine as long as you can cover the talent that will manage it. Thanks for your input.

Hi. Are you abstracting vsphere volumes with odf? I think it should work, but there would probably be some compromising like multiplication of replicas. Also probably some performance penalties. Probably best to reach out to your Red Hat rep for help.

Hi, are you using dvswitch or something else like nsx? If your network is already tagged at the hypervisor level then you should be able to just assign appropriate IPs and set up gateway and dns server. It's hard to help without all the details. Good luck!

Yes, that is a great summary. you got it

Glad you enjoyed it!

for disconnected you might want to consider a different installer. I recommend Agent Based

Thanks, @kevintunks739!

Thanks. DR requires at least couple of clusters to demonstrate. Hence, it's taking me a while to put it together.

Thanks Jean!

Interestingly enough I just worked on somewhat similar use case. Setting platform to none allowed me to bring my own load balancer - I have personally used HA Fortigate firewalls to also act as my load balancers. This is fairly fresh in my head so I would really want to make a video on it. It's hard for me to find a time these days

I am not sure. You would have to reach out to your Red Hat rep.

I don't have instructions for that but it should be somewhat similar.

I'd like to create another video with portworx, but didn't really have opportunity to do so.

Hi. Both Assisted and Agent Based would allow you to bond any interface you need - including the OCP base network. Just use the yaml editor. Example: interfaces: - name: bond0 type: bond state: up ipv4: address: - ip: X.X.X.X prefix-length: 24 dhcp: false enabled: true link-aggregation: mode: 802.3ad port: - ens1f0 - ens1f1 mtu: 9000

@@TrustedAdvisor-chrisj Thanks, this yaml option was not available in previous version. Looks good

the example here is not disconnected .. you would need to sync the image registries, create a mirror for disconnected and reference it in your configuration file

thank you for your comment, it's on the list .. just super hard to find time.

thanks. Yeah, it's on the list .. just super hard to find time.

The video or the platform ?

What hardware are you booting this on? It might be worth opening a support case with Red Hat.

Thanks for your comment. The benefits for the "all on public cloud" use case are: - ability to overcommit on resources (and not shared with others) - potential cost savings vs EC2 - 3rd party Software Defined Storage - and all the benefits that comes with it (live migration across AZs, DR etc) - arguably the best Kubernetes distribution to share between containers and VMs with all the awesome features built in - unlimited RHEL running on top (cost savings) There are tradeoff like increased complexity - since you are managing 2 stacks and the cost for smaller OCP clusters and no overcommit it going to be higher.

@TrustedAdvisor-tk8lj thanks for the answer. I am convinced :) Please keep it up sharing these contents. I like how you include, already in your video, many valid points we ask ourselves when choosing the best strategy. Have a good day.

@@Meme-2m2e - :-) .. I am glad you liked the video. Thanks for your feedback.