I just spent 2 hours trying to figure out why django celery stopped working.
Celery would being to start, but would stop short of printing out the configuration items, implying that it wasn't starting correct. The log would only contain
The celery.decorators module along with the magic keyword arguments,
are deprecated, and will be removed in version 3.0.
Please use the celery.task module instead of celery.decorators,
and the task.request should be used instead of the magic keyword arguments:
from celery.task import task
See http://bit.ly/celery22major for more information.
"""))
It turns out that some celery env variables that I was importing to try and fix a different problem were causing celery not to start correctly:
from celery.tests.config import CELERY_QUEUES, CELERY_DEFAULT_QUEUE, CELERY_DEFAULT_ROUTING_KEY
Even though I wasn't using them anywhere.
Does anyone know what was happening?
The constants I'm importing bring are actually constants defined for celery tests (celery.tests.config). When imported, their corresponding values into the scope of settings.py, so when celeryd runs, instead of defaulting to their (correct) respective values, celery ends up using the test CELERY_QUEUES defined in celery.tests.config.
Related
After I upgraded to Cypress 12, this problem started to happen. The only update to my code was upgrading cypress. The problem is that when I attempt to access an alias, some were accessible and others were not. In my test, I have aliased these two variables noRows and role_0
When I attempted to access them, noRows was accessible, but role_0 was not, and the test failed due to this.
This had no problem
But this had as the test kept trying to access it but was never able to do it.
This is where I alias them:
cy.get('#role_0').invoke('text').invoke('trim').as(`role_0`);
cy.wrap(index + 1).as('noRows');
And later in this test I attempt to access them:
cy.get('#noRows').then(noRows => {
cy.get(`#row`).should('have.length', noRows);
});
cy.get(`#role_0`).should('eq', shipment_ST);
Any ideas on how to solve this problem?
This might be due to the revamp of the alias behaviour in version 12.
Prior to 12, an alias would only try to re-evaluate when a "detached from DOM" error was found.
After 12 it re-evaluates all the time, but it introduced a breaking change if your test relies on the initial value.
This doesn't exactly sound like the problem you are describing, but it's worth trying the "fix" anyway.
See Changelog 12.4.0
The .as command now accepts an options argument, allowing an alias to be stored as type "query" or "static" value. This is stored as "query" by default. Addresses #25173.
So in your test, use .as('role_0', { type: 'static' }) to make it work more like a fixed variable rather than a retriable query.
I am experiencing weird behavior with YAML variables, parameters, and Azure pipeline resource references. The following shows the original implementation that works compared to my new implementation with a single line change that fails.
Working Implementation
Template A (makes a call to template B):
- template: Templates\TemplateB.yml
serviceBuildResourceName: resourceName
Template B (uses serviceBuildResourceName param to get pipeline run information):
$projectId = '$(resources.pipeline.${{ parameters.serviceBuildResourceName }}.projectID)'
$pipelineId ='$(resources.pipeline.${{ parameters.serviceBuildResourceName }}.PipelineID)'
Template B goes on to use the values in $projectId and $pipelineId (along with other values not listed here since it is irrelevant) to successfully retrieve information about the a pipeline run from the specific pipeline resource, serviceBuildResourceName. Note that all pipeline resources are correctly defined at the beginning yaml file for the pipeline. In this implementation above, everything works perfectly.
Failing Implementation
Template A (makes a call to template B):
- template: Templates\TemplateB.yml
serviceBuildResourceName: $(ServiceBuildResourceName)
Template B (uses serviceBuildResourceName param to get pipeline run information):
$projectId = '$(resources.pipeline.${{ parameters.serviceBuildResourceName }}.projectID)'
$pipelineId ='$(resources.pipeline.${{ parameters.serviceBuildResourceName }}.PipelineID)'
Note that the only difference is the following: instead of passing the hard-coded string into the serviceBuildResourceName parameter, I pass in a variable, which has the same value as before, resourceName. The variable is defined in an earlier template as such:
- name: ServiceBuildResourceName
value: resourceName
I feel it should still work the same, but I know get the following error in my pipeline run:
WARNING: 2023-02-12 15:52:29.5071 Response body: {"$id":"1","innerException":null,"message":"The value is not an integer.
$(resources.pipeline.resourceName.PipelineID)
I know that the variable is being correctly populated since the error message above contains "resourceName" in resources.pipeline.resourceName.PipelineID, as it should.
However, for reasons unknown to me, it now throughs an error. It seems like it doesn't recognize the pipeline resource, and instead recognizes it as a string.
Any help or insight here would be greatly appreciated, thanks!
As far as I can tell, this is because of how predefined variables work in YAML. Since resources.pipeline... is a predefined variable, it gets resolved at compile time. Thus, you can't use run-time defined variables like I am doing. Instead of resolving it as a predefined variable, it will get resolved to be a string at runtime.
I use pyinvoke which has a task decorator that works like this:
#task
def mycommand(
# MUST include context param even if its not used
ctx: Context
):
# Do stuff, but don't use ctx
Even if I don't use ctx I must include it for pyinvoke to work correctly. Pylint throws Unused argument 'ctx' Pylint(W0613:unused-argument).
From what I have read in GitHub issues it seems like it would be unreasonable to expect pylint to dig into decorators and figure them all out automatically.
I also don't want to turn off this pylint rule for the entire function.
Is there a way I can tell pylint that if the #task decorator is used do not apply the W0613 rule to the first argument of the function?
When there is code that is too dynamic and impossible to parse for pylint it's possible to create a "brain" i.e. a simpler version that will explain what the code does to astroid (the internal code representation of pylint). Generally this is what a pylint plugin does (for example pylint-django will do it for view function that need request, which is similar to your issue with ctx). Here's an example of brain for signal directly in astroid and the documentation. It's possible that a pylint plugin already exists so you don't have to do this yourself.
The four modules mentioned below are what are there in my site.pp file.
These four modules are written by me, they inturn use the Forge modules.For example, iis::install uses puppetlabs/windowsfeature module to install IIS and site::install uses puppetlabs/iis to create website and appPool that I require.
The problem that I am encountering is - Puppet rightly starts execution with iis::install but it does not finish executing this class fully. It keeps it in the background and then starts executing tools::install. As a result of wrong execution order, it fails completely
I am facing the exact same issue with the other two classes as well. It just starts executing site::install and then proceeds to include site::install. At the end, after the remaining classes complete execution, the classes in the background proceeds their execution
How can I inform Puppet in Site.pp file to complete the execution of first class before proceeding to the next
node default {
include iis::install
include tools::install
include site::install
include deploy::execute
}
Please read this article about resources ordering in puppet.
E.g you can use chaining arrows to define order between classes:
Class['iis::install'] -> Class['tools::install'] ->
Class['site::install'] -> Class['deploy::execute']
I have been unable to find a simple example which shows me how to use boto to terminate an Amazon EC2 instance using an alarm (without using AutoScaling). I want to terminate the specific instance that has a CPU usage less than 1% for 10 minutes.
Here is what I've tried so far:
import boto.ec2
import boto.ec2.cloudwatch
from boto.ec2.cloudwatch import MetricAlarm
conn = boto.ec2.connect_to_region("us-east-1", aws_access_key_id=ACCESS_KEY, aws_secret_access_key=SECRET_KEY)
cw = boto.ec2.cloudwatch.connect_to_region("us-east-1", aws_access_key_id=ACCESS_KEY, aws_secret_access_key=SECRET_KEY)
reservations = conn.get_all_instances()
for r in reservations:
for inst in r.instances:
alarm = boto.ec2.cloudwatch.MetricAlarm(name='TestAlarm', description='This is a test alarm.', namespace='AWS/EC2', metric='CPUUtilization', statistic='Average', comparison='<=', threshold=1, period=300, evaluation_periods=2, dimensions={'InstanceId':[inst.id]}, alarm_actions=['arn:aws:automate:us-east-1:ec2:terminate'])
cw.put_metric_alarm(alarm)
Unfortunately it gives me this error:
dimensions={'InstanceId':[inst.id]}, alarm_actions=['arn:aws:automate:us-east-1:ec2:terminate'])
TypeError: init() got an unexpected keyword argument 'alarm_actions'
I'm sure it's something simple I'm missing.
Also, I am not using CloudFormation, so I cannot use the AutoScaling feature. This is because I don't want the alarm to use a metric across the entire group, rather only for a specific instance, and only terminate that specific instance (not any instance in that group).
Thanks in advance for your help!
The alarm actions are not passed through dimensions but rather added as an attribute to the MetricAlarm object that you are using. In your code you need to do the following:
alarm = boto.ec2.cloudwatch.MetricAlarm(name='TestAlarm', description='This is a test alarm.', namespace='AWS/EC2', metric='CPUUtilization', statistic='Average', comparison='<=', threshold=1, period=300, evaluation_periods=2, dimensions={'InstanceId':[inst.id]})
alarm.add_alarm_action('arn:aws:automate:us-east-1:ec2:terminate')
cw.put_metric_alarm(alarm)
You can also see in the boto documentation here:
http://docs.pythonboto.org/en/latest/ref/cloudwatch.html#module-boto.ec2.cloudwatch.alarm