When working with a helm super-chart (umbrella chart) that consist of several sub-charts:
1 / if we attach a post-upgrade hook to one of the sub-chart, I wonder what is the expected behavior when running helm upgrade on the super-chart ?
1 - a / Assuming the sub-chart that contains the hooks has no changes at all, and there are changes in other sub-charts that do not have the hooks. Is the post-upgrade hooks supposed to be executed even tho, the sub-chart has no changes at all ?
Here is why i am asking the question:
In my understanding hooks are associated to release,
and sub-charts do not have their own release but are part of the umbrella chart
release. Hence, a post-upgrade hook should be executed only, if the
chart of the release changed and an upgrade is actually applied. By
that reasoning it would mean that (1) either hooks should only be
attached to the umbrella chart which has a release, (2) or if
attached to a sub-charts and it works nonetheless, then the hooks
would be fired anytime the upgrade command is applied on the super
charts. In other words, there would be no way to say, run the hooks
from that sub-chart, only if that sub-chart changes. That is, the
super-chart which is the only chart that yield a release, can be
subject to an upgrade, whenever any of its sub-chart changes. If
hooks are indeed strictly associated to release, even if that hooks is located in a
sub-chart, it would get triggered whenever the release to which the
sub-chart is part of is upgraded.
So far in our experiment we have attached the hooks that are related
to specific sub-chart in the super chart. It works but it is
annoying, because they are executed all the time, even when the
associated sub-chart did not change. We would to change it and attach
it to the sub-chart. However the spec does not say what is the
expected behavior, hence the question, so if/when experimenting, we would know if the
behavior that comes out, is the expected one or the result of configuring
something the wrong way.
Related
Did someone has a problem with email templates?
In my case when I use email template in Flow builder for trigger "checkout.order.payment_method.changed" email template with type "order confirmation" doesn't work properly. Problem with variables: currency and addresses are null but other variables works properly.
Interesting when I use the same template in Flow builder for trigger "checkout.order.placed" all vars working properly.
p.s. I've updated all extensions and my Shopware version is v6.4.9.0 Stable Version
Maybe it's a Shopware bug or conflict between plugins?
There are some inconsistencies regarding the data available between different Flow-Builder Events. I noticed something similar and created an issue for it here.
Maybe you can add your case there as this sounds related.
Without knowing the exact content of your order confirmation template, eg if it is the default content or if you made changes, it is hard to tell why this wouldn't work. I tested this on the latest release as of today 6.4.13.0 and the combination of said trigger and template seems to work fine. Looking at the history of the OrderStateChangeEventListener, the criteria for the order should've included currency and addresses associations for a while already, including your version. As #newgennerd already said there could potentially be differences between the criteria used for fetching order for state change events and those used for order placed events, as the latter would be the common use case for the order confirmation. So you should keep that in mind.
In my internal gitlab site there are a lot of repositories and I want to find repositories which don't' have commits for so long .
In order to do this , I searched as last updated but it's not accurately reflect , looks like it's a bug .
That could be similar to gitlab-org/gitlab-foss issue 56227:
For example, I have a project testing-dev-project in a group.
It displays that it was last updated 1 week ago.
Using the inspector, the time is Dec 28, 2018. However, if I query the project with the API, I get the "last_activity_at":"2018-10-26T12:46:34.372-07:00".
You can also check by going to the Project -> Activity or Project -> Settings -> Audit Events.
But:
This has likely always been the behavior - if a database migration touches something in a project then the updated_at timestamp is automatically updated by Rails.
This is also mentioned in gitlab-org/gitlab issue 25862: "Show project creation dates when sorting group page on this attribute"
For some reason, updated_at was updated fairly recently. I suspect a migration such as the one that encrypted the runners token column may have touched every project.
As a result, the updated_at column may have been updated recently, and the projects appear to have been touched more recently than they should.
Last updated being out of order due to the issues described in gitlab-org/gitlab-foss issue 27181
That last issue is the most relevant, still opened, and finishes with:
The discrepancy between the actual sort order and the displayed updated time is due to the fact that it displays the project's last_updated_date value, while sort is based on last_updated_at.
It's not immediately obvious to me why these values are so different, it seems like they should be very close.
I've submitted a MR that sets the list to display values from last_updated_at, though I'm not sure if a better long term solution would be to change the triggers that set last_updated_date and use that for sorting instead.
This issue is moved to gitlab-org/gitlab issue 17017.
See also GitLab 14.10 MR 82488: "Project list: order by real last update"
We have a complex scenario which requires a timer job to run after content deployment to a SP 2010 site collection. The timer job automatically deactivates/reactivates a branding feature which is responsible for setting the master page for the site collection, among other things.
We have had several feature upgrades along the way, and neglected to call .Update() on the feature in that specific site collection. So all of the updated CSS, master page, page layouts etc. are out of date on that SC.
The strange part is that when I checked the version number of that feature in this SC, it shows as the latest version. The custom upgrade action clearly didn't run and update the files, because nobody called .Upgrade().
One of my colleagues suggested that the deactivate/reactivate process done by the timer job would update the version number, meaning that I can no longer call Upgrade()!
Is that true? Does a deactivate/reactivate cycle for a feature automatically update the feature version number?
Is there an easy way to fix this mess? Some way to decrement the version number programmatically, then call Upgrade()??
On 1: No. Feature deactivating / activating does not trigger an update. See this article by Chris O' Brian: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade(), typically in conjunction with one of
the QueryFeatures() methods. My tool which I’ll go on to talk about is
a custom application page which helps you with this part – note there
is no STSADM command, PowerShell cmdlet or user interface to do this
out-of-the-box.
Is your timer job cycling the feature activation with Force? Then, yes, it is triggering the feature upgrade/feature update see the following screenshot from SPFeature.Activate (see my yellow marking):
Why the feature version is incremented, I'm not sure. When you have a feature, install a new feature version and activate / deactivate, the feature version stays the same unless you run an Upgrade, see also this related question stating the same: https://sharepoint.stackexchange.com/questions/41476/feature-upgrading-question
I'm guessing your timer job is using force? Otherwise I'm not quite sure what is happening.
On 2: Don't know if it is possible to decrease the version number, but the safest way would be to just create a new version including a grand "clean up" feature receiver which sets everything correct, i.e. checks which steps of the feature upgrade have happened already (e.g. new list created, new content type added) and which haven't. Depending on that just execute the same steps again which have not executed yet. For the latter part you can fortunately use the existing code, so you would only need the "clean up" or checking code.
After some testing I found that simply deactivating and reactivating the feature will increment the version number and completely screw up your upgrade! I even watched the update come through in the content database. As soon as you deactivate/reactivate the updated feature, the new version number pops into the content DB. Of course the upgrade doesn't actually run, it just increments the version number.
This means that if you then call .Upgrade() it won't work because SharePoint thinks it's already been upgraded!!
To fix this I updated the row in the content database to set the feature version back to 0.0.0.0 for that particular web and then I could run .Upgrade() just fine....but that's not exactly a supported solution. If anyone else has a better idea drop a reply.
I am Using Nagios XI. Currently My Nagios showing three states of alerts: CRITICAL, WARNING and OK.
I want to add another custom hard state FATAL for some extreme issues like server or any of my component(Java jar component) is down. Currently we are getting the DOWN message when the Host is Down. If the component is down I am getting "URL Status is CRITICAL" But I want "URL Status is FATAL". Is that possible to add a custom State in Nagios? How can I do that?
You can't. The states are built in (along with a fouth state, UNKNOWN, which is generally used if the plugin fails for reasons that probably belong to the plugin itself, not the object being monitored).
The states are intended to mean "requires action immediately (CRITICAL)" and "will probably require action soon (WARNING)". There's nothing left which would make your FATAL state different from CRITICAL, so i suggest you use that.
If you want to pass additional information to operators, you can always do that in the text the plugin provides.
(As Nagios is open source, you could probably modify the source code to allow another state. But this would be a huge task to implement properly, make your installation incompatible with the rest of the world, no plugins except yours would support it, and you'd have to re-apply and rewrite your patches with every new version of Nagios, so i'd strongly recommend against it).
You can't add states. But if you only want to make your alerts stand out more clearly, you can modify the nagios-Stylesheets in /etc/nagios3/stylesheets/ or add custom javascript in /usr/share/nagios3/htdocs/ssi/<nagiospage>-header.ssi and highlight the respective messages from there.
I am using JDeveloper 11.1.2.3.0
I am facing a strange behavior here. I have created 2 AppModules and in each AppModule I have DataControls from the same View Object (not only but also). When I create a new row using Page1 for example using DataControl from AppModule1 and then navigate to Page2 that uses DataControl from AppModule2, the Commit and Rollback buttons are enabled. Even if I redeploy the application in this case I have to Commit also in Page2. If I do this, then the problem will not show any more.
So even through I commit in the first case, I have to commit also in the second page. As I said the EO and VO are the same, just the AppModules are different.
Does anyone know why this happens and/or how to fix this?
If anyone knows that this is a known bug please tell me.
Well I hurried a little, I just found the solution (the problem actually). Apparently different app modules are completely ignored one by other and have their own db connections. The explanations is here:
http://www.jobinesh.com/2010/03/what-you-may-need-to-know-about-nested.html