Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ - batch-processing

On AzureML Batchendpoint, I'm recently hitting the following error:
Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ.
when I setup the batch-endpoint with a yml config:
environment: azureml:env-name:env-version
So, AzureML creates and builds the environment with the version I specify env-version, which is just a number (in my case = 3).
and then for some weird reason, AzureML creates an extra environment version called Autosave_(date)T(time)Z_********, which is not built, but based on the previous one just created, and then it becomes the latest version of that environment.
In summary, AzureML instead of looking for the version that I specified as env-name:3 it seems to be looking for env-name:Autosave_(date)T(time)Z_******** and then throws the error message mentioned above.

I found the problem was that when creating an environment from a YAML specification file, one of my conda dependencies was cmake, which I needed to allow installation of another python module. The docker image is exactly the same as a previously created environment.
Removing the cmake dependency from the YAML file, eliminated the issue. So the workaround is to install it using a Dockerfile.
The error message was very misleading to start with, but got there in the end after understanding that AzureML reuses a cached image, based on the hash value, from the environment definition accordingly to this
So for that reason, the automatically created Autosave docker image references to that same build, which only happens once when the first job is sent.

Related

How to run Odoo with OCA repositories' modules in Odoo.sh?

I am testing Odoo.sh, trying to run an Odoo 15 Enterprise. I read all the documentation and see several webinars about it, but I am not able to run an instance with any OCA module.
To do that, I followed these steps:
In the Odoo.sh interface, I created a new branch in the Development category, forking from main branch (the one in the Production category). Note: the main branch is the one created by default by Odoo.sh, I didn't make any modification on it and in fact it works OK, I can connect to it.
Also in the Odoo.sh interface, I clicked on the button Submodule and then on Run on Odoo.sh. In the opened pop-up, I added the OCA repository l10n-spain, (version 15.0 of course). The repository works perfectly in a local server. In fact you can try with other OCA repository, the result is going to be the same.
After doing that, Odoo.sh adds the repo to the project with a new [ADD] commit, and tries to make a build of it. However, the tests always fail.
If I go to the log, first, in the install.log section, I can see errors with Pip libraries, so I open a shell and try to fix them, with pip3 check and then adjusting the versions of the libraries it complains of.
After that, when I try to connect to the new build, the odoo.log starts being filled but also with errors, particularly this one:
WARNING xxx odoo.addons.base.models.ir_cron: Tried to poll an undefined table on database xxx.
ERROR xxx odoo.sql_db: bad query:
SELECT latest_version
FROM ir_module_module
WHERE name='base'
ERROR: relation "ir_module_module" does not exist
LINE 3: FROM ir_module_module
^
This error uses to appear when you do a wrong installation of Odoo, but the installation is done by Odoo.sh, so... how can I fix this?
Does anyone experienced the same? Any ideas? May be the Python libraries are the problem?
One problem can be that the requirements file brokest the installation. odoo.sh tries to install it automatically, and because odoo.sh is using outdated python modules, the installation usually breaks.
https://github.com/OCA/l10n-spain/blob/15.0/requirements.txt
You can try to copy the required modules directly to your repository.
Well, in the end I managed to connect to the build after open a shell and writing these commands:
odoosh-restart http
odoo-update all
Still didn't check which of them did the trick.

Building Superset locally encounters missing static assets

I'm trying to build Superset locally using docker-compose.
After cloning the repository, I modify docker-compose.yml so that it builds images from local source code instead of pulling from Docker Hub. My modifications include:
In service db, change Postgres image version from image: postgres:14 to image: postgres:10 since the service cannot be built properly with Postgres 14.
In services superset, superset-init, superset-worker, superset-worker-beat and superset-tests-worker, change image: *superset-image to build: . so that Docker builds the application from local source code.
However, after running docker-compose build and then docker-compose up, I got the blank screen like this. I checked out the logs and found out that a lot of asset files are missing, for example /static/assets/images/loading.gif is missing which results in that blank screen.
What am I wrong or missing from my configuration steps? Please help me.
I finally figured it out, it's because the webpackage of the superset frontend is installed inside the container superset_node instead of while building it. That's why although the superset_node is built, we have to wait (in my case for about 15-20 more minutes) for the webpackage to be completely installed. Another point to note is that this installation takes up a lot of memory, so make sure you allocate enough RAM to it (in my case I allocate 16GB to Docker).

<PATH_TO_SUMO>/bin/netedit: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: ecs_SetReportErrorFunction

Error:
<PATH_TO_SUMO>/bin/netedit: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: ecs_SetReportErrorFunction
This error appears when I try to run netedit. I have both the Webots simulation software, as well as the SUMO simulation software in my system and both, have netedit. When I remove either one of the software and then run netedit, it works. So, I think the issue is because of the presence of netedit twice. I was running netedit directly from the terminal but even after I give the exact path of the netedit I want to run, in a python script, and then run that script(For eg: I give the path of the netedit in SUMO), it shows this error. How to force the system to use a particular netedit (either webots' or SUMO's) whenever the netedit command is given?
This should be a question of setting your environment variable(s) PATH (and possibly LD_LIBRARY_PATH) to the correct values. If you install SUMO via the package manager of your Linux (apt or something) there should be nothing to adapt. I see from the Webots docs that they recommend manual adaption of those paths. If you don't do those changes or revert them you should be always using the netedit coming with plain SUMO. If you want to use the Webots version adapt the paths such that they list Webots directories first.

Installing Google Adwords Api Library (using docker)

Googles documentation on installing the library, found here: https://github.com/googleads/googleads-php-lib/blob/master/README.md#getting-started, instructs us to copy adsapi_php.ini, as constructed here: https://github.com/googleads/googleads-php-lib/blob/master/examples/AdWords/adsapi_php.ini, to your home directory.
I filled out the necessary variables in the .ini, and I am using docker so I have placed this file inside my container at /var/www/home/node/ and when I run the command composer require googleads/googleads-php-lib I am given the following error in the command prompt:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for googleads/googleads-php-lib ^37.1 -> satisfiable by googleads/googleads-php-lib[37.1.0].
- googleads/googleads-php-lib 37.1.0 requires ext-soap * -> the requested PHP extension soap is missing from your system.
To enable extensions, verify that they are enabled in your .ini files:
- /usr/local/etc/php/php.ini
- /usr/local/etc/php/conf.d/adsapi_php.ini
- /usr/local/etc/php/conf.d/docker-php-ext-pdo_pgsql.ini
- /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini
- /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.
Installation failed, reverting ./composer.json to its original content.
I assumed the issue was my adsapi_php.ini was simply in the wrong location as it contains what I believe is necessary to avoid the above issue, but I have tried placing it in several different places and yet I always get the same error.
Any help would be appreciated!
Just try to edit php.ini inside docker (docker exec -t {container} bashand enable there the extenstion soap

Asset pipeline creates empty Javascript file

I recently moved our QA Rails application on to a new server due to a corrupt disk. However the asset pipeline now creates an empty Javascript file. This does not happen locally when running rake assets:precompile.
The file created is called public/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.js`
The "e3b0c442" hash is the SHA-256 for an empty string.
Turns out we where using our own Javascript compressor, not the default one. Our compressor shells out to ugliferjs. Because it is a new server the latest version of ugliferjs was installed, via npm.
However one of the options we where passing to ugliferjs was no longer supported. It seems the errors, somewhere, was being silently swallowed.
Checking for the version of uglifierjs and passing different options for each fixed the issue.