In an example from AWS EC2 manual shows that we can perform apt update and upgrade by putting:
repo_update: true
repo_upgrade: true
But I can't find exactly same commands in cloud-init official documentation, so I keep looking for the similiar commands and found this, they give two commands package_upgrade and apt_upgrade but didn't tell the difference.
It makes me curious that what's the difference between repo_upgrade and package_upgrade and apt_upgrade
Yes this is quite puzzling, until I stumbled upon this, from which it seems that repo_upgrade applies to Amazon Linux only.
Also I found this ancient fan-made example.
It seems that most of the explanations are correct.
What I managed to find is
repo_upgrade description
(the source is Security updates section of Package repository topic - the official AWS Documentation)
package_update: (boolean) Set true to update packages. Happens before upgrade or install. Default: false.
package_upgrade: (boolean) Set true to upgrade packages. Happens before install. Default: false.
apt_update: (boolean) DEPRECATED: Dropped after April 2027. Use package_update. Default: false.
apt_upgrade: (boolean) DEPRECATED: Dropped after April 2027. Use package_upgrade. Default: false.
(see more details here)
Related
I want to use pulumi in my CI and do commands like this:
export DATABASE_PASSWORD=$(pulumi config get dbPassword)
but how to I stop this from printing into it:
warning: A new version of Pulumi is available. To upgrade from version '2.12.1' to '2.13.0', visit https://pulumi.com/docs/reference/install/ for manual instructions and release notes.
It's possible to skip the update check by setting the PULUMI_SKIP_UPDATE_CHECK environment variable to a truthy value. See also: https://www.pulumi.com/docs/reference/cli/environment-variables/
After Changing to version 1.19, but using Omnipath implementation, I'm randomly receiving the following error: ERROR calling: gasnet_barrier_try(id, 0).
I know that the Omnipath implementation of GASNet is no longer supported by the current version of Chapel. However, I would like to use some features available only in version 1.19, and the cluster I use runs over an Omnipath network.
In order to use the PSM substrate (OmniPath), I proceed as suggested by Chapel's Gitter community:
export CHPL_GASNET_ALLOW_BAD_SUBSTRATE=true
wget https://gasnet.lbl.gov/download/GASNet-1.32.0.tar.gz
tar xzf GASNet-1.32.0.tar.gz
rm -rf $CHPL_HOME/third-party/gasnet/gasnet-src
mv GASNet-1.32.0 $CHPL_HOME/third-party/gasnet/gasnet-src
Then, I setup other variables:
export CHPL_COMM='gasnet'
export CHPL_LAUNCHER='gasnetrun_psm'
export CHPL_COMM_SUBSTRATE='psm'
export CHPL_GASNET_SEGMENT='everything'
export CHPL_TARGET_CPU='native'
export GASNET_PSM_SPAWNER='ssh'
export HFI_NO_CPUAFFINITY=1
Next, I build the runtime, etc.
However, when I run experiments, I randomly receive the following error:
ERROR calling: gasnet_barrier_try(id, 0)
at: comm-gasnet.c:1020
error: GASNET_ERR_BARRIER_MISMATCH (Barrier id's mismatched)
Which finishes the execution of the program.
I cannot find in GASNet documentation the reason for this error. I could only find a bit of information on GASNet's code.
Do you know what's the cause of this problem?
Thank you all.
I realize this is an old question, but for the record the current version of Chapel (1.28.0) now embeds a version of GASNet (GASNet-EX 2022.3.0 as of this writing) that provides CHPL_COMM=gasnet CHPL_COMM_SUBSTRATE=ofi (aka GASNet ofi-conduit) that provides high-quality support for Intel Omni-Path.
In particular, there should no longer be any reason to clobber Chapel's embedded version of GASNet-EX with an ancient/outdated GASNet-1 to get Omni-Path support, as suggested in the original question.
For more details see Chapel's detailed Omni-Path instructions.
I'm trying to automize WebSphere Deployment process for zero down-time using steps which you can find in this link..
According to documentation's first step , we should disable "Automatic Synchronization" for each node. To automize it, I'm using script which given in documentation but when I try to apply the command below :
set syncServ [$AdminConfig list ConfigSynchronizationService $na_id]
I'm facing with an error that : ADMG0007E: The configuration data type ConfigSynchronizationService is not valid
As I checked IBM documentations, I couldn't see any resource which referred to this problem.
Does anyone have any workaround or direct solution for it?
Thanks in advance for your suggestions.
PS: I should mention that document written for zOS system but I'm trying to apply that methodology to WebSphere AS on Linux.
I want to run spring xd with Oracle(11g) which i already have in my environment. Currently my first concern is the jobs UI (my database has existing data of job executions that were performed by spring-batch and i simply want to display the details of those executions).
i'm using spring-xd-1.0.0.M5. I followed the instructions in the reference guide and i changed application.yml to have the following:
spring:
datasource:
url: jdbc:oracle:oci:MY_USERNAME/MYPWD#//orarmydomain.com:1521/myservice
username: MY_USERNAME
password: MYPWD
driverClassName: oracle.jdbc.OracleDriver
profiles:
active: default,oracle
i modified also batch-jdbc.properties to have the database configuration similar to the above.
Yet, when i start xd-singlnode.bat (or either xd-admin.bat) it seems like it ignores my oracle configuration and still uses the default hsqldb.
what am i doing wrong?
Thanks
The likely reason is that we did not upgrade the windows .bat scripts to take advantage of the property overriding via xd-config.yml. If you go into the unix script for xd-singlenode you will see that when java is invoked there there is an option
-Dspring.config.location=$XD_CONFIG
you can for now hardcode your location of that file, use file: as the prefix.
Also, The UI right now is very primitive, you will not be able to see many details about the job execution. There are however many job related commands you can execute in the shell and there is only one gap regarding step execution information as compared to what is available via spring-batch-admin.
The issue to watch for this is https://jira.springsource.org/browse/XD-1209 and it is schedule for the next milestone release.
Let me know how it goes, thanks!
Cheers,
Mark
I'm trying to set a custom value for the logLevel parameter to my MongoDB installation. The standard way to do it seems to pass a --setParameter argument to the mongod.exe executable.
But I read the Configuration File Options page, and it indicates that it is possible to include the setParameter within a configuration file.
What's the syntax in this case?
As of MongoDB 2.4, there are now version-specific online manuals for MongoDB. If you look at the navigation at the top left of the page, you should see a dropdown with available manual versions (eg. "2.4 (current)" or "2.2"). The default manual matches the current stable production release.
The setParameter configuration syntax is new to 2.4 (and noted as such in the 2.4 manual).
The historical syntax for setting logLevel/verbosity is to use an increasing number of vs (for verbosity, aka --verbose). So v is loglevel 1, vv is loglevel 2, and so on.
This config setting will work in MongoDB 2.2 and older versions as well as MongoDB 2.4:
// Set verbosity to logLevel 3:
vvv = true
In general you won't want to set a logLevel higher than 1 unless trying to collect information for troubleshooting purposes. The normal level of logging verboseness is 0; higher levels can generate a lot of logging details.