OpenWISP/general

General OpenWISP Chat

Gagan Deep

@pandafy

@pandafy https://github.com/openwisp/openwisp-utils/pull/113#issuecomment-637443504

Replied :smile:

Ajay Tripathi

@atb00ker

Thanks! :smile:

Pablo Castellano

@PabloCastellano

I'm confused with the settings CELERY_TASK_ALWAYS_EAGER and CELERY_TASK_EAGER_PROPAGATES in openwisp-firmware-upgrader. I cannot find documentation about them, however there is documentation about CELERY_ALWAYS_EAGER and CELERY_EAGER_PROPAGATES. Are these defined somewhere else or are we using old setting names? Any idea @nemesisdesign ?

Federico Capoano

@nemesisdesign

I am not sure @PabloCastellano, I see it's mentioned here: https://docs.celeryproject.org/en/stable/django/first-steps-with-django.html

https://docs.celeryproject.org/en/stable/userguide/configuration.html#std:setting-task_always_eager

Federico Capoano

@nemesisdesign

openwisp-utils 0.5 is out: https://twitter.com/pypi_updates2/status/1267885450003431424
Thanks @atb00ker for releasing it :+1:

Expect some builds to fail because of this :wink:

Federico Capoano

@nemesisdesign

@nepython I think somewhere you asked me what I mean for "future proof", I can't find it.
I meant calling super() instead of duplicating the method code, because so if the upstream code is refactored or changed we won't have to change our code as well.

Federico Capoano

@nemesisdesign

Reviewed https://github.com/openwisp/openwisp-monitoring/pull/113#pullrequestreview-423175925 as well

Hardik Jain

@nepython

Thanks @nemesisdesign. I think you found the PR and replied upon it :smile:

Hardik Jain

@nepython

Anyone observing similar failures like this. I am observing it from morning in all PRs but all tests are passing locally. So, it seems it's due to some change in a module on which openwisp-monitoring depends :smiley:

It might not be due to the new release of openwisp-utils because openwisp-monitoring builds were already installing the unreleased version from openwisp-utils repo.

replicajune

@replicajune

this is probably a newbie question but let's go anyway : I'm trying to set a template to configure dropbear but variables in uci refer to dynamic fields (or field that seems like they can change name). I see I can access the variables I want using @name[int] but I think applying this in a template doesnt work. here is the exemples:

# this is what I see doing "uci show dropbear"
dropbear.cfg014dd4=dropbear
dropbear.cfg014dd4.RootPasswordAuth='on'
# I can see the same variables doing "uci show dropbear.@dropbear[0]"
# however, having a template like this doesn't work:
{
    "dropbear": {
        "@dropbear[0]": {
            "RootPasswordAuth": "off",
            "PasswordAuth": "off"
        }
    }
}

It's most probably a naive aproach but I would like to understand how to access dropbear.cfg014dd4 in a secure and consistant way ^^

Hardik Jain

@nepython

Anyone observing similar failures like this. I am observing it from morning in all PRs but all tests are passing locally. So, it seems it's due to some change in a module on which openwisp-monitoring depends :smiley:

Well, I found the issue was with the latest release of Celery. They have fixed it in the repo (celery/celery#6146) but are yet to release an update on pypi.
Options currently,

Fix the version of celery to previous version 4.4.3 which didn't had this issue (probably).
Install celery from source for now.
Templorarily add future in travis until new release of celery.

Pablo Castellano

@PabloCastellano

In 4.4.3 they have also changed something that made openwisp-firmware-upgrader tests start failing - openwisp/openwisp-firmware-upgrader#78

Federico Capoano

@nemesisdesign

this is probably a newbie question but let's go anyway : I'm trying to set a template to configure dropbear but variables in uci refer to dynamic fields (or field that seems like they can change name). I see I can access the variables I want using @name[int] but I think applying this in a template doesnt work. here is the exemples:
# this is what I see doing "uci show dropbear"
dropbear.cfg014dd4=dropbear
dropbear.cfg014dd4.RootPasswordAuth='on'
# I can see the same variables doing "uci show dropbear.@dropbear[0]"
# however, having a template like this doesn't work:
{
    "dropbear": {
        "@dropbear[0]": {
            "RootPasswordAuth": "off",
            "PasswordAuth": "off"
        }
    }
}
It's most probably a naive aproach but I would like to understand how to access dropbear.cfg014dd4 in a secure and consistant way ^^

The syntax is slightly different: http://netjsonconfig.openwisp.org/en/latest/backends/openwrt.html#all-the-other-settings

@replicajune :point_up:

you can use variable in the configuration.
The only problem is frontend validation that now doesn't play well with it. We're trying to solve it.
But the problem may manifest or not depending on which part of the configuration you use.

Anyone observing similar failures like this. I am observing it from morning in all PRs but all tests are passing locally. So, it seems it's due to some change in a module on which openwisp-monitoring depends :smiley:

Well, I found the issue was with the latest release of Celery. They have fixed it in the repo (celery/celery#6146) but are yet to release an update on pypi.
Options currently,

Fix the version of celery to previous version 4.4.3 which didn't had this issue (probably).

Install celery from source for now.

Templorarily add future in travis until new release of celery.

@nepython @PabloCastellano I would try using the dev version of celery, if the problem is fixed with that I would ask the celery devs to issue another minor release
@auvipy :point_up:

Federico Capoano

@nemesisdesign

Actually, 11 hours ago they released 4.4.4: https://github.com/celery/celery/releases/tag/v4.4.4

Hardik Jain

@nepython

and 2 hours later the PR which added the dependency was made. See here

replicajune

@replicajune

thank yo uvery much for the answer Federico ! much apreciated :)

Federico Capoano

@nemesisdesign

@nepython @PabloCastellano I suspect celery broken backward compatibility inadvertently, this should be a temporary workaround and should be valid for both monitoring and firmware-upgrader (since they depend on controller): openwisp/openwisp-controller#202

Federico Capoano

@nemesisdesign

guys, when you create branches for pull requests, try to name them "issue/<number>-<short-description>"

otherwise I go crazy

Noumbissi Valere

@NoumbissiValere

Ok @nemesisdesign :smile:

Gagan Deep

@pandafy

:+1:

Hardik Jain

@nepython

:+1:

Ajay Tripathi

@atb00ker

Released: https://pypi.org/project/django-netjsongraph/

(Last release before deprecating module! :smile:)

Ajay Tripathi

@atb00ker

And the release has a problem! :-(

@nepython check here: https://github.com/openwisp/django-netjsongraph/commit/ab8de783b71864e06cf0e0dc5d564559df3f21cd#diff-e80164e07bad1abc78210b9c1ce81555R4

The difference between base classes & normal tests classes is that base classes are used in any module that extends the django-netjsongraph, example openwisp-network-topology.
If we import models like Link in the base classes, the extended module will fail as django-netjsongraph is not in it's INSTALLED_APPS; I am fixing this now but informing just incase it'll be useful with other modules in the future. (although since we are moving to swapper in all modules, maybe it wouldn't be the case in future -- i.e the base classes wouldn't even exist!)

Ajay Tripathi

@atb00ker

@nepython btw, fix -> openwisp/django-netjsongraph#128

Hardik Jain

@nepython

Thanks, @atb00ker for informing. I didn't knew how swappable models work exactly back then :sweat_smile:

Ajay Tripathi

@atb00ker

:+1:

Federico Capoano

@nemesisdesign

And the release has a problem! :-(
@nepython check here: https://github.com/openwisp/django-netjsongraph/commit/ab8de783b71864e06cf0e0dc5d564559df3f21cd#diff-e80164e07bad1abc78210b9c1ce81555R4
The difference between base classes & normal tests classes is that base classes are used in any module that extends the django-netjsongraph, example openwisp-network-topology.
If we import models like Link in the base classes, the extended module will fail as django-netjsongraph is not in it's INSTALLED_APPS; I am fixing this now but informing just incase it'll be useful with other modules in the future. (although since we are moving to swapper in all modules, maybe it wouldn't be the case in future -- i.e the base classes wouldn't even exist!)

Oh I didn't spot that.

Federico Capoano

@nemesisdesign

Regarding the celery issue: https://groups.google.com/d/msg/celery-users/QBv2HaPL-j4/cXaCReybAAAJ

Federico Capoano

@nemesisdesign

I can't believe it.. the Peruvian government extended the lockdown measures for 90 days more.
I want to get out of here.

Ajay Tripathi

@atb00ker

@nemesisdesign Remember the days when we thought it's only going to be only a 10-15 day thing? :joy:

Federico Capoano

@nemesisdesign

Damn. I thought maximum 3 weeks.
I overestimated the smartness of our fellow humans.
It's really bad here. Numbers are going up no matter all the restrictions.
Sometimes I go for a walk at night to curious around and I see a lot more people and cars than what I should see, supposedly it's curfew, but it's just a farse really.

I understand many people need to work day by day to survive here but I don't think that's the problem.
The problem is just that average person is not intelligent. They take stupid risks for no gain.

So now winter is approaching here and I expect things will get worse.

Oliver Kraitschy

@okraits

It's only logical that it will take months to years

Anything else would be a surprise

Ajay Tripathi

@atb00ker

It's only logical that it will take months to years

Yeah, I mean, it's obvious now but in Feb & March, the talks & news was like 10 days to curfew would be enough and blah blah...

Ajay Tripathi

@atb00ker

I understand many people need to work day by day to survive here but I don't think that's the problem.
The problem is just that average person is not intelligent. They take stupid risks for no gain.

I think It's also education, at least here in India and I expect Peru as well because Peru is also developing nation. Because of our education we are able to understand and grasp the idea of non-linear increase of the disease and the theory of tragedy of masses.
I don't think it's fair to expected less educated people to get it -- and of course then they have worry about the day-to-day work as well.

Oliver Kraitschy

@okraits

Yeah, that's true, you're right

Federico Capoano

@nemesisdesign

I understand many people need to work day by day to survive here but I don't think that's the problem.
The problem is just that average person is not intelligent. They take stupid risks for no gain.

I think It's also education, at least here in India and I expect Peru as well because Peru is also developing nation. Because of our education we are able to understand and grasp the idea of non-linear increase of the disease and the theory of tragedy of masses.
I don't think it's fair to expected less educated people to get it -- and of course then they have worry about the day-to-day work as well.

Look, people in the US are well educated, I don't think they're that less educated than people in Italy or India. In the big Brazilian cities people are far richer and better educated than Peru. But still, very high numbers.
Death rate is worse there than Peru and India.
From what I observe, the outcome of the pandemic mainly depends on 2 things:

the measures imposed by the authority need to be well balanced and effective
citizens must follow the emergency laws imposed by the authority

in Peru, the government acted early. The police at some point gave up because they were dying arresting people.
The government was not quick enough to quarantine big cities and it also applied weird measures.
But hey, it's hard to govern a country in a pandemic. I understand them.
Who I do not understand are all those market workers that insisted in working with their mask taken off to their neck.
That's plain stupidity.
I say that because I have to shop there, I go to these markets.

The good thing is that now they're finally understanding how dirty they are and are finally implementing good hygienic measures in these markets, using gloves, installing glasses, refrigerators for meat and fish and so on.

In the past when I went to these markets I couldn't stand the smell. You can understand it's a dirty an unhygienic place from hundred of meters away.

Federico Capoano

@nemesisdesign

but anyway.. this is really OT haha :joy:

Where communities thrive

People

Repo info

Activity