{"push_id":1100104781,"size":4,"distinct_size":0,"ref":"refs/heads/master","head":"9be253271ec1587e97099ff3e7ed3f223d0bb2f3","before":"373a3b9e2da18ea5febd3b8dc6cc432f96df59e4","commits":[{"sha":"fa4749659915b73e8b8ba00526a8ed83ddc41942","author":{"email":"6f9af0692a7d1f914f468ec8416a8e6aa93178b4@gmail.com","name":"Gerd Behrmann"},"message":"srm: Split into frontend and backend services\n\nMotivation:\n\nThe motivation for this patch goes all the way back to around 2008. At the\ntime BNL wanted to scale the SRM by separating the GSI authentication from\nthe SRM request processing, allowing the part with the authentication to\nbe horizontally scaled.\n\nAt the time we were using Tomcat, SRM was purely integrated with dCache,\nand the design ideas revolved around using an external messaging system\nto bind the frontends and backends. This never materialized.\n\nThe problem however persists. Despite improvements in the software and\nvastly more powerful hardware, SRM authentication is expensive and forms\na hard limit on the request throughput of the SRM.\n\nModification:\n\nSplit the SRM service into two components: A frontend containing Jetty,\nAxis, and the callout to gPlazma; and a backend containing the request\nprocessing, including persistence in a database.\n\nThe frontend service is still called srm, while the backend is called\nsrmmanager. The srmmanager service is currently not scalable, but the\nfrontend can be scaled at will. An external load balancing mechanism\n(round robind DNS, load balancing switch) has to be used to make the\nfrontends appear as one to the clients.\n\nThe frontend and backends are regular dCache services and communicate\nover cells message passing.\n\nBoth the SRM and GridSite servlets are split in this manner.\n\nResult:\n\nSplits the srm service into two: A frontend service called srm, and a backend\nservice called the srmmanager. The frontend contains the Jetty webserver\nand performs the authentication, while the backend contains all the\nsrm request processing and requires access to the srm database.\n\nThe frontend can be scalled at will, using a common backend.\n\nMany configuration properties that used to belong to the srm service\nare now obsolete and have been moved to the srmmanager service instead.\n\nNote that it is the frontend that is advertised as a door in the info\nservice. For this reason both the frontends and the backend need to be\nconfigured with a common name space root path.\n\nIt is no longer necessary to maintain a vomsdir configuration on neither\nthe frontend nor backend service. The srm frontend relies on gPlazma for\nthis functionality.\n\nIn contrast to before, the gridsite delegation service now requires that\nthe user is authorized through gPlazma.\n\nUpon upgrade, as a minmum an srmmanager service needs to be added to the\nlayout file. It is recommended to place this before the srm service. If\nany srm properties are set, these should be updated as necessary in case\nthese now belong to the srmmanager service.\n\nTarget: trunk\nRequire-notes: yes\nRequire-book: yes\nAcked-by: Paul Millar <paul.millar@desy.de>\nAcked-by: Dmitry Litvintsev <litvinse@fnal.gov>\n\nReviewed at https://rb.dcache.org/r/9243/","distinct":false,"url":"https://api.github.com/repos/alrossi/dcache-server/commits/fa4749659915b73e8b8ba00526a8ed83ddc41942"},{"sha":"27ceae761fe2c7801e81a4b152700dffef9af579","author":{"email":"6f9af0692a7d1f914f468ec8416a8e6aa93178b4@gmail.com","name":"Gerd Behrmann"},"message":"doors: Add properties to allow loginbroker address, port and root path to be configured\n\nMotivation:\n\nIn HA setup one will typically have a proxy in front of the doors. Thus the\naddress seen by a client is different from the address on which a door listen.\nThis must be reflected in the information published in the information system.\n\nModification:\n\nIntroduces *.loginbroker.{address,port,root} properties to allow the published\naddress and root path to be set independently of the real values of the door.\n\nResult:\n\nOne can configure alternative endpoint addresses and root paths to be published by\nsetting the new *.loginbroker.{address,port,root} properties.\n\nTarget: trunk\nRequire-notes: yes\nRequire-book: yes\nAcked-by: Paul Millar <paul.millar@desy.de>\n\nReviewed at https://rb.dcache.org/r/9244/","distinct":false,"url":"https://api.github.com/repos/alrossi/dcache-server/commits/27ceae761fe2c7801e81a4b152700dffef9af579"},{"sha":"451be4b1626e20e807af2167f87e21888d997aa7","author":{"email":"6f9af0692a7d1f914f468ec8416a8e6aa93178b4@gmail.com","name":"Gerd Behrmann"},"message":"srmmanager: Allow horizontal scaling of the srm backend\n\nMotivation:\n\nHorizontal scalability, high availability, rolling upgrades.\n\nModification:\n\nLet the SRM manager register itself in ZooKeeper under /dcache/srm/backends/.\nThe znode name is a hash of the fully qualified cell address (the id) and the\nznode data is the cell address. The risk of collisions is considered so low\nthat there is no special logic for this case.\n\nThe backend's id is also included in the response sent back to the frontend.\n\nThe frontend modifies the request token to prefix it with the backend id.\nOn receiving requests including a request token, this id is mapped back to\na cell address and identifies the owning backend.\n\nResult:\n\nAllows multiple SRM backends. The backends serving a common cluster of\nfrontends should have a common service name. Each backend should have its own\ndatabase. Requests are partitioned among available backends, providing\nhorizontal scalability. If a backend goes offline, the requests it hosts become\nunavailable. New requests can however be submitted to remaining backends.  A\nbackend can be drained by unsubscribing it from its named queue by deleting the\nroute. Note that an SRM cell should not be renamed nor moved to a different\ndomain without first draining it.\n\nTarget: trunk\nRequire-notes: yes\nRequire-book: yes\nAcked-by: Paul Millar <paul.millar@desy.de>\nAcked-by: Dmitry Litvintsev <litvinse@fnal.gov>\n\nReviewed at https://rb.dcache.org/r/9245/","distinct":false,"url":"https://api.github.com/repos/alrossi/dcache-server/commits/451be4b1626e20e807af2167f87e21888d997aa7"},{"sha":"9be253271ec1587e97099ff3e7ed3f223d0bb2f3","author":{"email":"bef81794fc39da6ac6706cc6fffcec49fd61a00f@outlook.com","name":"Anupam Ashish"},"message":"webdav: fixed broken HTTP Basic Authentication\n\nHttp Basic Authentication was broken and was not triggering a browser\nlogin prompt. This resulted in authorization denied.\n\nIt was caused by the missing \"WWW-Authenticate\" header. Also, setting\nthe realm from webdav.xml.\n\nTicket: http://rt.dcache.org/Ticket/Display.html?id=8963\nFixes: #2398\nAcked-by:\nTarget: trunk\nRequire-book: no\nRequire-notes: yes\nRequest: 2.15\nPatch: https://rb.dcache.org/r/9257/","distinct":false,"url":"https://api.github.com/repos/alrossi/dcache-server/commits/9be253271ec1587e97099ff3e7ed3f223d0bb2f3"}]}