search

cvmfs-contrib / config-repo

Master source for CVMFS configuration repository for major organizations
4 stars 19 forks source link

Setting Denver cache to use pelican/osdf cache #253

Closed biozit closed 2 months ago

biozit commented 3 months ago

Setting Denver cache to use pelican/osdf cache

DrDaveD commented 3 months ago

I am confused. Why use https for unauthenticated data?

biozit commented 3 months ago

Using the Pelican Software, the ports are the same for both services.

matyasselmeci commented 3 months ago

It looks like we can use both https and plain http on that port if that's better.

DrDaveD commented 3 months ago

That doesn't help me. Why change the Denver cache to use https port 8443 for CVMFS?

Separately, you do have me curious too: why does Pelican use the same port for both services? Are you saying it always uses https on port 8443 for authenticated and unauthenticated services, or that it always uses port 8443 for both http and https?

matyasselmeci commented 3 months ago

Pelican only has a single instance of xrootd, listening on port 8443. This can be used for both auth and unauth access; if you don't need to pass a credential, you can use plain http on that same port.

DrDaveD commented 3 months ago

Oh, this is Pelican server software. I didn't know that was a thing, I only heard about the client.

So then the question is why should the server software be non-standard? Why not have it also listen on port 8000, for http? If nothing else it will save a lot of effort in changing the cvmfs configuration over one by one as the servers are converted. As it is there will be transition problems as the servers are cut over, because cvmfs only reads the configuration at mount time. A repository can stay mounted for weeks or even months.

DrDaveD commented 3 months ago

It's also possible to set up iptables to forward one port to another. I assume nftables has a way too although I haven't yet tried it.

biozit commented 3 months ago

Let me try something using k8s tricks

--Fábio Andrijauskas

On Tue, Apr 30, 2024 at 2:40 PM DrDaveD @.***> wrote:

It's also possible to set up iptables to forward one port to another. I assume nftables has a way too although I haven't yet tried it.

— Reply to this email directly, view it on GitHub https://github.com/cvmfs-contrib/config-repo/pull/253#issuecomment-2087427867, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEEH77HIKOLSROPDQOAHPDZAAFWDAVCNFSM6AAAAABHAZK5FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBXGQZDOOBWG4 . You are receiving this because you authored the thread.Message ID: @.***>

biozit commented 2 months ago

I can't use k8s tricks here, we are checking the best solution.

bbockelm commented 2 months ago

@biozit - can you open a second Kubernetes port in the deploy and map it to the same port inside the container? That'll provide the backward compatibility that @DrDaveD is looking for.

In the meantime, I think it'd be good to merge this to try and discover any issues. If we map both ports to the single port inside the container, we could do a single subsequent update for all the other caches.

biozit commented 2 months ago

Brain, all OSDF k8s hosts are using “hostnetwork,” we can't do that

--Fábio Andrijauskas

On Wed, May 1, 2024, at 2:02 PM Brian P Bockelman @.***> wrote:

@biozit https://github.com/biozit - can you open a second Kubernetes port in the deploy and map it to the same port inside the container? That'll provide the backward compatibility that @DrDaveD https://github.com/DrDaveD is looking for.

In the meantime, I think it'd be good to merge this to try and discover any issues. If we map both ports to the single port inside the container, we could do a single subsequent update for all the other caches.

— Reply to this email directly, view it on GitHub https://github.com/cvmfs-contrib/config-repo/pull/253#issuecomment-2089135446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEEH77IXL7A3LCHQF7NM5TZAFJ7PAVCNFSM6AAAAABHAZK5FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGEZTKNBUGY . You are receiving this because you were mentioned.Message ID: @.***>

DrDaveD commented 2 months ago

In the meantime, I think it'd be good to merge this to try and discover any issues.

If we need to merge it temporarily I'd rather have it be http than https. Also this is on the master branch and it needs to be on the osg branch in order to be ready to deploy. If it's just a temporary change then we might as well make it only on the osg branch.

If we map both ports to the single port inside the container, we could do a single subsequent update for all the other caches.

One change is better than lots, but if it is set up to listen on both 8000 and 8443, wouldn't we just switch this one back and leave it on 8000? It's very unusual/surprising to use http on port 8443.

biozit commented 2 months ago

@bbockelm @DrDaveD, could we approve this PR to start the tests?

DrDaveD commented 2 months ago

I would rather have a PR against the osg branch that uses http instead of https.

bbockelm commented 2 months ago

We can do that - but it's going to guarantee that there's going to be subsequent updates. Long-term, we plan to transition to HTTPS-only.

DrDaveD commented 2 months ago

Long-term, we plan to transition to HTTPS-only.

What's the point of doing that for CVMFS, which is already guaranteeing the integrity at a higher level?

biozit commented 2 months ago

https://github.com/cvmfs-contrib/config-repo/pull/254

jthiltges commented 2 months ago

I believe this is resolved with #254. Please reopen if needed.