search

dmwm / DBS

CMS Dataset Bookkeeping Service
Apache License 2.0
7 stars 21 forks source link

Update the cmsweb usage to port 8443. #568

Closed bbockelm closed 6 years ago

bbockelm commented 6 years ago

Fixes #561

@vkuznet

cmsdmwmbot commented 6 years ago

Jenkins results:

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-DBS-PR-test/70/artifact/artifacts/PullRequestReport.html

ticoann commented 6 years ago

@yuyiguo, WMAgent is moving to port 8443 in this deployment. Could you check the code again and plan for next cms deployment as well.

yuyiguo commented 6 years ago

@ticoann @amaltaro I started to make change to DBS code to use port 8443 yesterday. I'd like make everything from 443 to 8443. This include my VM testbed. I just realized thatI cannot change DBS to 8443 without agreement with all DBS clients. I would say you would hold your changes to WMAgent until others in the same page. I will send out email and see what others schedule on this.

amaltaro commented 6 years ago

Yuyi, I don't think we need to have any agreement on it. CMSWEB has already been configured to listen on port 443 and 8443, so any requests to data-services hosted in cmsweb could either go to the default https port 443, or we change it to 8443.

Having dbsClient using port 8443 by default can go in parallel with any of these changes. BTW, besides CRAB and WMCore, are there any other customes of dbsClient?

belforte commented 6 years ago

I am curious... forgive me. Since everybody is supposed to talk with DBS only via CMSWEB, ad CMSWEB accepts both 8443 and 443, what's the point in moving DBS-to-CMSWEBfrontend from 443 to 8443 ? Is this going to help the docker/kubernetes thing ? Or is WMCore now going to talk to DBS w/o the cmsweb i/f ? (wow !!)

yuyiguo commented 6 years ago

Allan, Good to know that CMSWEB is configured to access to both 443 and 8443. There are a lot of script to call DBS using either DBS client or REST APIs.

PerilousApricot commented 6 years ago

My concern on the HN was that once the deployment was done, there would be applications who expect to talk on 443 being unable to connect. In that case, there would have to be a flag day where everyone changed their configuration in lockstep with the CMSWEB change.

If everyone using 443 can still connect like how they were before, then my concern was unfounded.

belforte commented 6 years ago

@amaltaro we can't really answer the question "who else may be using DBS3 client" since it is a public client and we put instructions on how to use it in the twiki years ago. Do we need to break it ? If not.. what's the right question ?

yuyiguo commented 6 years ago

@PerilousApricot I totally understood your concern. We have to wait for Lina to confirm that DBS can/will be accessed from both 8443 and 443. Thank you very much for bringing this up.

amaltaro commented 6 years ago

I don't know what the final goal is, but AFAIK both ports will remain up and this is how we can distinguish (and maybe provide some QoS?) between end users and CMS services accessing cmsweb web services. So I'd say your concern is unfounded, Andrew :) https://cmsweb.cern.ch/dbs/prod/global/DBSReader/filesummaries?dataset=/WprimeToENu_M_4800_Tune4C_13TeV_pythia8/Phys14DR-TEST_PU20bx25_PHYS14_25_V1_TEST_Alan-v9/AODSIM https://cmsweb.cern.ch:8443/dbs/prod/global/DBSReader/filesummaries?dataset=/WprimeToENu_M_4800_Tune4C_13TeV_pythia8/Phys14DR-TEST_PU20bx25_PHYS14_25_V1_TEST_Alan-v9/AODSIM

Stefano, yes, my question wasn't the best one. Maybe the correct question is: who provides a CMS (production) service that uses the dbsClient. I know any user can install the RPM and start using it, but ideally they should not be using port 8443 and that should be left for real services/software talking to DBS (WMAgent/WorkQueue/TaskWorker/McM/?)

belforte commented 6 years ago

Alan, yes, thanks. About (WMAgent/WorkQueue/TaskWorker/McM/?) add CRAB REST and ASO, or just put CRAB in place ot TaskWorker, also because ASO will disappear and we have anyhow a new service called Publisher which takes over the publish-to-DBS part of ASO. Anyhow.. CRAB (i.e. me) is aware.

ticoann commented 6 years ago

If a lot of users use dbs client api, I think we might need to have default port 443 for client and overwrite that port to 8433 any of our application use (DBS, WMAgent, Crab, Unifided).

I think WMAgent can do that by changing secrete file url.

FYI, some background of the issue. https://github.com/dmwm/DBS/issues/561

belforte commented 6 years ago

561 was indicating that dbs client port shoudl be (easily) selectable. So users can stick with default and services do something different.

yuyiguo commented 6 years ago

@ticoann @amaltaro @bbockelm I am confused after all the discussion. I was not very clear that why we need to move to 8443. I thought that DBS would only run on 8443 and 443 port will be used for something else after a while. If both 8443 and 443 will be open forever for different user groups, why we need any code changes in this PR? No matter you use DBS client or REST API, as long as both ports are open to DBS, DBS will not need to do anything. The end user will choose which port they use. Since most scripts are using the default port 443 and most people will not bother to put 8443 in the URL, WMAgent, Crab or any other services just need to put 8443 in their URL to DBS no matter they use DBS client or REST API.

What I missed here?

ticoann commented 6 years ago

No matter you use DBS client or REST API, as long as both ports are open to DBS, DBS will not need to do anything. The end user will choose which port they use. Since most scripts are using the default port 443 and most people will not bother to put 8443 in the URL, WMAgent, Crab or any other services just need to put 8443 in their URL to DBS no matter they use DBS client or REST API.

I might be wrong but I think above statement is correct. @bbockelm, @amaltaro, @vkuznet, Maybe DBS doesn't need to do anything for changing the port, it is responsibility of using DBS api.

Is there any calls made internally in dbs to cmsweb? (migration, unittest, etc). I think only those need to change the port to 8443.

yuyiguo commented 6 years ago

Where to migration is also the users’ choice. DBS will nor hard code any url.

If you look closely, all the changes in the PR are comments that have URL or different kind of tests. But the tests are against to testbed and who cares which port to test if both ports are open.

From: Seangchan Ryu notifications@github.com Reply-To: dmwm/DBS reply@reply.github.com Date: Wednesday, August 15, 2018 at 12:14 PM To: dmwm/DBS DBS@noreply.github.com Cc: Yuyi Guo yuyi@fnal.gov, Mention mention@noreply.github.com Subject: Re: [dmwm/DBS] Update the cmsweb usage to port 8443. (#568)

No matter you use DBS client or REST API, as long as both ports are open to DBS, DBS will not need to do anything. The end user will choose which port they use. Since most scripts are using the default port 443 and most people will not bother to put 8443 in the URL, WMAgent, Crab or any other services just need to put 8443 in their URL to DBS no matter they use DBS client or REST API.

I might be wrong but I think above statement is correct. @bbockelmhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bbockelm&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=J3npDPRWoW5QxcVBkvEEfURYrwWqnBFY_jSaHyW_gBE&s=GQQV1BdYn4kGWThVD7j9LyAbvw0UIBd1rn5cyZmefbo&e=, @amaltarohttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_amaltaro&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=J3npDPRWoW5QxcVBkvEEfURYrwWqnBFY_jSaHyW_gBE&s=W8b4suvkRJYcW2eRbqoH7SUCcejUoIua9xAgJ116GLo&e=, @vkuznethttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vkuznet&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=J3npDPRWoW5QxcVBkvEEfURYrwWqnBFY_jSaHyW_gBE&s=He2bWQeeSHIolHjI7SzQ8TkmqxTtXsqSVk-OOA9AQkg&e=, Maybe DBS doesn't need to do anything for changing the port, it is responsibility of using DBS api.

Is there any calls made internally in dbs to cmsweb? (migration, unittest, etc). I think only those need to change the port to 8443.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dmwm_DBS_pull_568-23issuecomment-2D413267923&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=J3npDPRWoW5QxcVBkvEEfURYrwWqnBFY_jSaHyW_gBE&s=hxrsmhFloki-nAmaKMs9C0vl8U6E-Unl6S_xe3Md8kU&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABsXTjBKi8H-2Dw-5FdN7cuMFPBTc8iN7Equks5uRFbvgaJpZM4T8Qfj&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=J3npDPRWoW5QxcVBkvEEfURYrwWqnBFY_jSaHyW_gBE&s=bwNA7lgb6f7pos6pX0Vewcdz_42haax5FUSEGyA76iU&e=.

amaltaro commented 6 years ago

Yuyi, IF DBSServer doesn't need to query any other CMSWEB service, then yes, there are no changes actually needed. About tests, I still think they should be pointing to port 8443. We never know when jenkins will go rogue and fire hundreds of thousands of queries to cmsweb and, if it does, it's better to have them going to port 8443.

yuyiguo commented 6 years ago

Alan:

We never tested against cmsweb prod, all tests point to testbed. In addition, I don't see there is any difference between 8443 and 443 for any of the unit tests if both ports are open.

ticoann commented 6 years ago

@yuyiguo, Hi Yuyi, I think there is some misunderstanding. The port division is not for the functionality. It is for the machine auto generated statistics, so any cms applications we supports would go 8443 and all other user usage will use port 433. So we can analyze the usage for that. (I might be wrong on the purpose of this port division. @bbockelm, @vkuznet, @amaltaro please correct me if I am wrong.

That is why we are changing the port for cmsweb access in all agent as far as I understood.

vkuznet commented 6 years ago

Hi, let me clarify few things in this discussion. The migration to port 8443 is due to the fact that we plan to migrate from X509 to a new schema (token based) authentication. Under new proposal all machine tools will use port 8443 while all web clients (literally end-user using web browsers) will use default port 443 on cmsweb and eventually migrate to SSO based authentication rather X509. The port 8443 will be used by all machine tools where we rely on x509 and later tokens. So, it is functionality change and it has nothing to do with gathering statistics (even though it is not prohibited and will be used).

Lina and I already made both ports available on prod and pre-production) cmsweb nodes.

Therefore we need to start migration of all machine based clients (which means every script which use DBS) to use port 8443. Obviously it should be transparent. As such the changes should be made at low level DBS APIs which should query DBS server on that port. For users (tools) who rely on DBS APIs my understanding it should be transparent, while DBS APIs itself should internally start using port 8443.

Best, Valentin.

On 0, Seangchan Ryu notifications@github.com wrote:

@yuyiguo, Hi Yuyi, I think there is some misunderstanding. The port division is not for the functionality. It is for the machine auto generated statistics, so any cms applications we supports would go 8443 and all other user usage will use port 433. So we can analyze the usage for that. (I might be wrong on the purpose of this port division. @bbockelm, @vkuznet, @amaltaro please correct me if I am wrong.

That is why we are changing the port for cmsweb access in all agent as far as I understood.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dmwm/DBS/pull/568#issuecomment-413328681

belforte commented 6 years ago

Thanks Valentin, indeed a different authorization mechanism is "a different QoS" as Alan wrote. but please keep in mind that same script could be used by machine or by users. Unless we introduce a clean separation of which falls in which category, hardcoding port in DBS utils script may lead to confusion when the new authentication methods will be rolled in.

I fully do not understand your last sentence[1], can you possibly elaborate ? What happens to e.g. a script of mine which runs on lxplus and uses DBS API ? [1] " For users (tools) who rely on DBS APIs my understanding it should be transparent, while DBS APIs itself should internally start using port 8443."

vkuznet commented 6 years ago

Stefano, we want to separate web clients from machine tools. That's it. The web client is a browsers, everything else is machine tools. Therefore your "user" based script which uses DBS API is a machine tool.

Best, Valentin.

On 0, Stefano Belforte notifications@github.com wrote:

Thanks Valentin, indeed a different authorization mechanism is "a different QoS" as Alan wrote. but please keep in mind that same script could be used by machine or by users. Unless we introduce a clean separation of which falls in which category, hardcoding port in DBS utils script may lead to confusion when the new authentication methods will be rolled in.

I fully do not understand your last sentence[1], can you possibly elaborate ? What happens to e.g. a script of mine which runs on lxplus and uses DBS API ? [1] " For users (tools) who rely on DBS APIs my understanding it should be transparent, while DBS APIs itself should internally start using port 8443."

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dmwm/DBS/pull/568#issuecomment-413369536

belforte commented 6 years ago

I see. So that means that eventually I (users) will need to learn how to use those tokens. At some point there will be a transition X509 --> tokens for everybody. Fine with me, simply I had understood differently in the past. My bad. The scenario which you describe makes sense to me. Thanks for having made this clear.

On 16/08/18 01:33, Valentin Kuznetsov wrote:

we want to separate web clients from machine tools. That's it. The web client is a browsers, everything else is machine tools. Therefore your "user" based script which uses DBS API is a machine tool.

ticoann commented 6 years ago

Thanks Valentin, I completely misunderstood the purpose of this change. Now it is clear why we are doing this.

amaltaro commented 6 years ago

I guess everyone misunderstood it, including myself (which means, lack of communication :))

amaltaro commented 6 years ago

Valentin, reading again your reply, this change does affect every single CMS user. The only distinction is between web browsing and machine/script usage. This change cannot be transparent but for those using dbsClient. All the other usage of cmsweb services / REST APIs are not covered, and I bet there are plenty of scripts out there using those APIs.

I don't want to hijack this DBS issue, but creating issues for DMWM projects is only the very first step of this transition. Is there any strategy to roll these changes out? I also think this should go to a wider audience, e.g.: 1) webtools and oc-dmwm egroups should ALL be contacted with a clear plan and instructions 2) then web-interfaces HN 3) lastly, cern-comp-announcements HN

according to the plans that you/CMSWEB/DMWM L2s have come up with.

belforte commented 6 years ago

Alan, x509->tokens will NOT be transparent. Not even for those using dbsClient. Port change is not what worries me: it is work, but doable and with a well defined end, misunderstanding will be cleared, details defined, bugs sorted out.. done. But everything else is still too fuzzy to comment w/o risking guessing (we just witnessed a massive failure of guesswork). We need a proper forum for this, and a much better described plan than what was exposed so far, all the way up to how to change user instructions in the workbook ! I will save all my other comments for the new thread.

yuyiguo commented 6 years ago

Comments from Valentin: "Therefore we need to start migration of all machine based clients (which means every script which use DBS) to use port 8443. Obviously it should be transparent. As such the changes should be made at low level DBS APIs which should query DBS server on that port. For users (tools) who rely on DBS APIs my understanding it should be transparent, while DBS APIs itself should internally start using port 8443."

I want to make it clear one more time. DBS APIs ( Client APIs or REST APIs) do not have hard coded URL inside it. Whoever calls DBS should provide the proper url. So there is no such thing called "DBS APIs itself should internally start using port 8443".

I suggested Seangchan and Alan change your WMAgent DBS API calls using 8443 against the testbed or prod to see how DBS works. Please let us know if there is any new deployment/changes needed from DBS after all.

Regarding the authorization mechanism changes as Valentin pointed, we need a overall CMSWEB wide planning to bring all the applications/users to use a proper mechanism. This is beyond DBS.

vkuznet commented 6 years ago

Yuyi, as we suggested on a meeting, the DBS should take care of port transition. If DBS code does this

dbs_client --url=

then dbs_client (I put it as abstract name not as concrete one) will take provided url, strip it apart and add port if necessary.

This will create transparency to all clients who will still use url as is (since port 443 is a default one and it is not required in url).

The dbs client will take care of translating the given url into url:port underneath.

Does it make sense?

And, let's not mix the authorization plan into this discussion.

The only thing people need to know right now that request for moving to port 8443 is part of bigger plan which will eventually help us to move from x509 to token based authorization. The details will come later and in fact they will be more transparent (since we'll deal with HTTP headers).

Best, Valentin.

On 0, Yuyi Guo notifications@github.com wrote:

Comments from Valentin: "Therefore we need to start migration of all machine based clients (which means every script which use DBS) to use port 8443. Obviously it should be transparent. As such the changes should be made at low level DBS APIs which should query DBS server on that port. For users (tools) who rely on DBS APIs my understanding it should be transparent, while DBS APIs itself should internally start using port 8443."

I want to make it clear one more time. DBS APIs ( Client APIs or REST APIs) do not have hard coded URL inside it. Whoever calls DBS should provide the proper url. So there is no such thing called "DBS APIs itself should internally start using port 8443".

I suggested Seangchan and Alan change your WMAgent DBS API calls using 8443 against the testbed or prod to see how DBS works. Please let us know if there is any new deployment/changes needed from DBS after all.

Regarding the authorization mechanism changes as Valentin pointed, we need a overall CMSWEB wide planning to bring all the applications/users to use a proper mechanism. This is beyond DBS.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dmwm/DBS/pull/568#issuecomment-413571521

yuyiguo commented 6 years ago

Valentin:

Your explanation on why we need to moving to 8443 was really appreciated. I wished this was communicated earlier. With this in mind, Adding a 8443 to a default DBS client port would make sense. But I do think the plan should be let the developers know as well as the large community as soon as possible. I don't think anyone wants to do his/her work blindly.
Thanks, Yuyi