-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting connect string from SiteLocalConfig #31544
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31544/18553
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: CondCore/ESSources @smuzaffar, @Dr15Jones, @makortel, @christopheralanwest, @tocheng, @cmsbuild, @tlampen, @ggovi, @pohsun can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test FYI @hernand |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
if (siteLocalConfig.isAvailable()) { | ||
std::string const& localConnectPrefix = siteLocalConfig->localConnectPrefix(); | ||
std::string const& localConnectSuffix = siteLocalConfig->localConnectSuffix(); | ||
if (!localConnectPrefix.empty() && !localConnectSuffix.empty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the suffix be allowed to be empty?
How about SiteLocalConfig
would have a function telling if the local-config
was specified or not, and then using the prefix and suffix without further checks here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable. I will change the code so that if is present in the XML, then the connection string will be changed to prefix + globaltag + suffix, even if the prefix and suffix are empty or not specified in the XML. I will push a commit with this change soon.
m_localConnectPrefix = safe(connectString->Attribute("prefix")); | ||
m_localConnectSuffix = safe(connectString->Attribute("suffix")); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make the <frontier-connect>
and <local-connect>
elements mutually exclusive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will make the change such that the SiteLocalConfigService constructor will throw an exception if both <frontier-connect>
and <local-connect>
are present. This seems reasonable to me.
This means someone creating a new XML file for one of these sites will have to both delete the <frontier-connect>
section and add the <local-connect>
. They will not be able to be lazy and just add <local-connect>
and the other one then gets ignored. It is more work to edit the XML, but should be easier for someone to understand what is happening when reading the XML file.
Comparison is ready Comparison Summary:
|
529704b
to
7134489
Compare
On Oct 1, 2020, at 2:09 PM, Marco Musich ***@***.***> wrote:
@davidlange6
Nah - we do this routinely in all productions #27393
If I am not mistaken I said exactly that , quoting myself:
A part from the AlCa/DB team actively chasing overrides of the production location for retrieving conditions (issue #27393), so once that's done normally all the conditions needed to run a production workflow should come from same GlobalTag ESSource, there are few places in which the GlobalTag overide is done on purpose by means of so-called "symoblic Global Tags"
I assume someone is following up on that issue. Once that's solved the other point will still be there.
Indeed, if thats true, thats great - ideas on the timescale? I looks like all the originally reported ones are still there.
|
My impression is that the proposal of this PR has not been fully understood here. There are two issues that are ( in my opinion ) well separated:
|
@mmusich whatever cannot be fully traced and reproduced within a db query, for me falls into category one of the issues... |
I am not sure to follow you. The tags I am talking about are fully traced by the CMSSW configuration and reproduced by a DB queury, only they are not directly associated with any "physical" Global Tag. If this use-case is not supported anymore (to which I don't really object), then please agree with the AlCa part of the project to support multiple Global Tag Queues for upgrade purposes. What is in place now is necessary as they did not agree to the extra burden of maintaining several different additional queues. |
@mmusich The key point is the user-case. In what respect this is a special case and in what differs from the normal GT-centralized treatment? An hard-coded tag ( if this is the case ) is pretty much equivalent to a toGet statement, and therefore should be avoided. But maybe I'm missing something? |
@mmusich Ok I see that your use case is driven by the intention to keep to a reasonable volume the amount of GT queues that AlCa need to support. Now I remind the discussions... |
@wddgit @makortel @christopheralanwest @hernand @mmusich |
This is week is generally bad because of the ongoing O&C week. Would next week work, or does the PPD workshop interfere? (if it does, how about two weeks from now?) |
Ok. I guess next week will be equally hard to find a slot for everybody. Let's move it tentatively for the week of 26 October. |
@wddgit @makortel @christopheralanwest @hernand @mmusich |
Fine with me on Monday 16h. I can prepare a couple of slides with the use case |
Monday at 16h works for me as well. Thanks @hernand for preparing slides. |
@makortel @hernand @wddgit @christopheralanwest @mmusich |
Was the decision at the meeting to go ahead with this? Are we still waiting for more discussion? Was there something I needed to change? |
For what I am concerned, we can go ahead. In the future, we might need some adaptation if the single file GT is replaced by a folder structure. |
+1 |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Add support for setting the connection string in PoolDBESSource based on the site local config XML file and the global tag. Here is an example of of how to modify the XML file:
If a non-empty globaltag is in the PoolDBESSource configuration and
<local-connect>
is in the XML file as shown above, then the connection string will be overwritten by the result of concatenating the prefix plus the globaltag plus the suffix. The prefix and suffix are from the XML file and can be set to anything or nothing.An exception will be thrown if
<local-connect>
and<frontier-connect>
are both set in the same XML file.It is also possible to override the prefix and suffix from the configuration of the SiteLocalConfigService. It is also possible to force overwriting of the connection string in the same way.
This is primarily intended for use at sites where the worker nodes do not have network connectivity and the data normally retrieved from a database must be put into a local file.
PR validation:
Extended SiteLocalConfig unit tests to cover these new variables.
This should not change any behavior or results until a site local config XML file modified or the override configuration parameters are used. Existing tests of PoolDBESSource verify that.
We have not yet tested this on remote worker nodes that do not have network connectivity. The intent is to do that testing after the PR is merged and if necessary make further changes.