What specific configuration or syntax changes must be made in order to resolve the The system cannot find the path specified. error that terraform is throwing when it tries to load a provider from a local mirror?
THE PROBLEM
A local file system mirror for terraform providers is re-used in an automation program.
The console prints out The system cannot find the path specified. during the third use of the same provider by the third module that tries to download the module within 2 minutes.
The first two times the same provider is requested from the same local file system mirror succeed within a couple minutes before this error is thrown.
The problem persists when the calling program sleeps 360 seconds before each request in an attempt to avoid possible locking causes. 6 minute delay does not prevent problem.
THE PROVIDER EXE FILE EXISTS
The terraform-provider-aws_v3.22.0_x5.exe provider file does indeed appear when we view it in Windows Explorer. Then, we we right click on the exe file and open the properties window, the location and file name are given as:
C:\projects\TERRAF~1\29DEC2~1\TERRAF~2\CALLS-~1\INSTAN~1\SUBNET~1\DEMO-D~1\TERRAF~1\PROVID~1\REGIST~1.IO\HASHIC~1\aws\322~1.0\WINDOW~1
Then when we run a dir command to explore the directory, we also see the following:
C:\path\to\some\directory>dir C:\projects\TERRAF~1\29DEC2~1\TERRAF~2\CALLS-~1\INSTAN~1\SUBNET~1\DEMO-D~1\TERRAF~1\PROVID~1\REGIST~1.IO\HASHIC~1\aws\322~1.0\WINDOW~1
Volume in drive C is Windows
Volume Serial Number is DAB2-5285
Directory of C:\projects\TERRAF~1\29DEC2~1\TERRAF~2\CALLS-~1\INSTAN~1\SUBNET~1\DEMO-D~1\TERRAF~1\PROVID~1\REGIST~1.IO\HASHIC~1\aws\322~1.0\WINDOW~1
12/29/2020 01:36 PM <DIR> .
12/29/2020 01:36 PM <DIR> ..
12/29/2020 01:36 PM 175,883,264 terraform-provider-aws_v3.22.0_x5.exe
1 File(s) 175,883,264 bytes
2 Dir(s) 736,395,243,520 bytes free
COMPLETE STACK TRACE
The complete TRACE output of the terraform command is as follows:
Initializing provider plugins...
- Finding latest version of hashicorp/aws...
2020/12/29 13:36:35 [TRACE] getproviders.SearchLocalDirectory: C:\path\to\terraform\providers is a symlink to C:\path\to\terraform\providers
2020/12/29 13:36:35 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/aws v3.22.0 for windows_amd64 at C:\path\to\terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64
2020/12/29 13:36:35 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/http v2.0.0 for windows_amd64 at C:\path\to\terraform\providers\registry.terraform.io\hashicorp\http\2.0.0\windows_amd64
2020/12/29 13:36:35 [TRACE] providercache.Dir.InstallPackage: installing registry.terraform.io/hashicorp/aws v3.22.0 from C:\path\to\terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64
- Installing hashicorp/aws v3.22.0...
2020/12/29 13:36:35 [TRACE] providercache.fillMetaCache: scanning directory .terraform\providers
2020/12/29 13:36:35 [TRACE] getproviders.SearchLocalDirectory: .terraform\providers is a symlink to .terraform\providers
2020/12/29 13:36:35 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/aws v3.22.0 for windows_amd64 at .terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64
2020/12/29 13:36:35 [TRACE] providercache.fillMetaCache: error while scanning directory .terraform\providers: cannot search .terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64\terraform-provider-aws_v3.22.0_x5.exe: CreateFile .terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64\terraform-provider-aws_v3.22.0_x5.exe: The system cannot find the path specified.
Error: Failed to install provider
#JohnHanley's SUGGESTION
Per #JohnHanley's suggestion in the comments, we reset the `` registry key to 1 and then opened a different instance of Windows CMD, navigated to the same directory, and ran the same automation program.
The program now stops at the same place as before, but this time the program hangs in definitely instead of explicitly throwing an error.
Here is the new console output up to the point where it hangs:
Initializing provider plugins...
- Finding latest version of hashicorp/aws...
2020/12/29 15:39:21 [TRACE] getproviders.SearchLocalDirectory: C:\path\to\terraform\providers is a symlink to C:\path\to\terraform\providers
2020/12/29 15:39:21 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/aws v3.22.0 for windows_amd64 at C:\path\to\terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64
2020/12/29 15:39:21 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/hashicorp/http v2.0.0 for windows_amd64 at C:\path\to\terraform\providers\registry.terraform.io\hashicorp\http\2.0.0\windows_amd64
2020/12/29 15:39:21 [TRACE] providercache.Dir.InstallPackage: installing registry.terraform.io/hashicorp/aws v3.22.0 from C:\path\to\terraform\providers\registry.terraform.io\hashicorp\aws\3.22.0\windows_amd64
- Installing hashicorp/aws v3.22.0...
The error messages indicate a MAX_PATH problem. A side issue is that the path is using the DOS namespace. The solution is to either reorganize the directory structure to shorten the path or use UNC Paths.
For the DOS namespace, applications are often coded to support a maximum length of 255 characters. For the LONG namespace the maximum length is 260 characters of which the directory portion cannot exceed MAX_PATH - 12 (248) characters. The terminating NULL consumes one character.
Enable Long Paths in Windows 10, Version 1607, and Later
Related
I'm try configuring GitLab to save terraform state.
I set my main.tf file as below:
terraform {
backend "http" {
address = "https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>"
lock_address = "https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>/lock"
unlock_address = "https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>/lock"
username = "myuser"
password = "<Token-ID>"
lock_method = "POST"
unlock_method = "DELETE"
retry_wait_min = 5
}
}
I can run only the first time, terraform init,terraform plan and terrafrom apply
The state is saved correctly on my GitLab project (under Infrastructure->Terraform).
But it I try to re-run terraform init I receive this error:
Initializing modules...
Initializing the backend...
2022/01/28 17:06:24 [DEBUG] GET https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>
Error refreshing state: Failed to read remote state: unexpected EOF
Note: my terraform files are not in the main root project, but in a subfolder:
/<Name-Project>/<terraform-folder>/main.tf
How can fix my problem?
UPDATE:
Now I receive this error when I run terraform plan:
Error: error loading state: Failed to read remote state: stream error: stream ID 3; INTERNAL_ERROR
These are the terraform logs:
2022-02-08T10:34:03.690Z [INFO] Terraform version: 1.1.4
2022-02-08T10:34:03.700Z [INFO] Go runtime version: go1.17.2
2022-02-08T10:34:03.701Z [INFO] CLI args: []string{"terraform", "plan", "-out=plan.out"}
2022-02-08T10:34:03.701Z [TRACE] Stdout is a terminal of width 120
2022-02-08T10:34:03.704Z [TRACE] Stderr is a terminal of width 120
2022-02-08T10:34:03.704Z [TRACE] Stdin is a terminal
2022-02-08T10:34:03.704Z [DEBUG] Attempting to open CLI config file: /root/.terraformrc
2022-02-08T10:34:03.705Z [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-02-08T10:34:03.706Z [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-02-08T10:34:03.706Z [DEBUG] ignoring non-existing provider search directory /root/.terraform.d/plugins
2022-02-08T10:34:03.706Z [DEBUG] ignoring non-existing provider search directory /root/.local/share/terraform/plugins
2022-02-08T10:34:03.708Z [DEBUG] ignoring non-existing provider search directory /usr/local/share/terraform/plugins
2022-02-08T10:34:03.710Z [DEBUG] ignoring non-existing provider search directory /usr/share/terraform/plugins
2022-02-08T10:34:03.711Z [INFO] CLI command args: []string{"plan", "-out=plan.out"}
2022-02-08T10:34:03.717Z [TRACE] Meta.Backend: built configuration for "http" backend with hash value 1000000006
2022-02-08T10:34:03.721Z [TRACE] Preserving existing state lineage "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
2022-02-08T10:34:03.721Z [TRACE] Preserving existing state lineage "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
2022-02-08T10:34:03.722Z [TRACE] Meta.Backend: working directory was previously initialized for "http" backend
2022-02-08T10:34:03.729Z [TRACE] Meta.Backend: using already-initialized, unchanged "http" backend configuration
2022-02-08T10:34:03.737Z [TRACE] Meta.Backend: instantiated backend of type *http.Backend
2022-02-08T10:34:03.741Z [TRACE] providercache.fillMetaCache: scanning directory .terraform/providers
2022-02-08T10:34:03.743Z [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/tpretz/zabbix v0.15.0 for linux_amd64 at .terraform/providers/registry.terraform.io/tpretz/zabbix/0.15.0/linux_amd64
2022-02-08T10:34:03.744Z [TRACE] providercache.fillMetaCache: including .terraform/providers/registry.terraform.io/tpretz/zabbix/0.15.0/linux_amd64 as a candidate package for registry.terraform.io/tpretz/zabbix 0.15.0
2022-02-08T10:34:03.861Z [DEBUG] checking for provisioner in "."
2022-02-08T10:34:03.866Z [DEBUG] checking for provisioner in "/usr/bin"
2022-02-08T10:34:03.867Z [TRACE] Meta.Backend: backend *http.Backend does not support operations, so wrapping it in a local backend
2022-02-08T10:34:03.869Z [INFO] backend/local: starting Plan operation
2022-02-08T10:34:03.871Z [TRACE] backend/local: requesting state manager for workspace "default"
2022-02-08T10:34:03.872Z [TRACE] backend/local: requesting state lock for workspace "default"
2022-02-08T10:34:03.873Z [DEBUG] POST https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>/lock
2022-02-08T10:34:04.127Z [TRACE] backend/local: reading remote state for workspace "default"
2022-02-08T10:34:04.127Z [DEBUG] GET https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>
2022-02-08T10:34:04.475Z [DEBUG] DELETE https://<myGitLab>/api/v4/projects/<ID-Project>/terraform/state/<Project-Name>/lock
I am trying to test out some new code for a terraform provider and for reasons I don't understand, it seems to want to try and find a resource definition with hashicorp, even though it's specifically defined within this provider. Obviously I am missing something:
Code to [provider][1]:
This is how I build and install it:
christianb#unifi terraform-provider-artifactory % rm -fR .terraform
christianb#unifi terraform-provider-artifactory % go build && mkdir -p .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64 && mv terraform-provider-artifactory .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64
now running it
christianb#unifi terraform-provider-artifactory % TF_LOG=trace terraform init
2021/02/25 13:12:56 [INFO] Terraform version: 0.13.5
2021/02/25 13:12:56 [INFO] Go runtime version: go1.14.10
2021/02/25 13:12:56 [INFO] CLI args: []string{"/usr/local/bin/terraform", "init"}
2021/02/25 13:12:56 [DEBUG] Attempting to open CLI config file: /Users/christianb/.terraformrc
2021/02/25 13:12:56 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Users/christianb/.terraform.d/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Users/christianb/Library/Application Support/io.terraform/plugins
2021/02/25 13:12:56 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2021/02/25 13:12:56 [INFO] CLI command args: []string{"init"}
Initializing the backend...
2021/02/25 13:12:56 [TRACE] Meta.Backend: no config given or present on disk, so returning nil config
2021/02/25 13:12:56 [TRACE] Meta.Backend: backend has not previously been initialized in this working directory
2021/02/25 13:12:56 [DEBUG] New state was assigned lineage "b7f7e5b9-b88c-6195-aaaf-e38b3008b8e5"
2021/02/25 13:12:56 [TRACE] Meta.Backend: using default local state only (no backend configuration, and no existing initialized backend)
2021/02/25 13:12:56 [TRACE] Meta.Backend: instantiated backend of type <nil>
2021/02/25 13:12:56 [DEBUG] checking for provisioner in "."
2021/02/25 13:12:56 [DEBUG] checking for provisioner in "/usr/local/bin"
2021/02/25 13:12:56 [INFO] Failed to read plugin lock file .terraform/plugins/darwin_amd64/lock.json: open .terraform/plugins/darwin_amd64/lock.json: no such file or directory
2021/02/25 13:12:56 [TRACE] Meta.Backend: backend <nil> does not support operations, so wrapping it in a local backend
2021/02/25 13:12:56 [TRACE] backend/local: state manager for workspace "default" will:
- read initial snapshot from terraform.tfstate
- write new snapshots to terraform.tfstate
- create any backup at terraform.tfstate.backup
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2021/02/25 13:12:56 [TRACE] statemgr.Filesystem: read nil snapshot
2021/02/25 13:12:56 [TRACE] providercache.fillMetaCache: scanning directory .terraform/plugins
2021/02/25 13:12:56 [TRACE] getproviders.SearchLocalDirectory: .terraform/plugins is a symlink to .terraform/plugins
Initializing provider plugins...
2021/02/25 13:12:56 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/jfrog/artifactory v2.2.6-alpha for darwin_amd64 at .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64
2021/02/25 13:12:56 [TRACE] providercache.fillMetaCache: including .terraform/plugins/registry.terraform.io/jfrog/artifactory/2.2.6-alpha/darwin_amd64 as a candidate package for registry.terraform.io/jfrog/artifactory 2.2.6-alpha
2021/02/25 13:12:56 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2021/02/25 13:12:56 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
- Using previously-installed jfrog/artifactory v2.2.6-alpha
- Finding latest version of hashicorp/xray...
2021/02/25 13:12:56 [DEBUG] GET https://registry.terraform.io/v1/providers/hashicorp/xray/versions
2021/02/25 13:12:56 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/hashicorp/xray/versions
2021/02/25 13:12:57 [TRACE] providercache.fillMetaCache: using cached result from previous scan of .terraform/plugins
2021/02/25 13:12:57 [DEBUG] GET https://registry.terraform.io/v1/providers/-/xray/versions
2021/02/25 13:12:57 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/-/xray/versions
Error: Failed to install provider
Error while installing hashicorp/xray: provider registry registry.terraform.io
does not have a provider named registry.terraform.io/hashicorp/xray
terraform to run:
# Required for Terraform 0.13 and up (https://www.terraform.io/upgrade-guides/0-13.html)
terraform {
required_providers {
artifactory = {
source = "registry.terraform.io/jfrog/artifactory"
version = "2.2.6-alpha"
}
}
}
provider "artifactory" {
url = "http://localhost:8082/artifactory"
username = "admin"
password = "password"
}
resource "xray_policy" "test" {
name = "test-policy-name"
description = "test policy description"
type = "security"
rules {
name = "rule-name"
priority = 1
criteria {
min_severity = "High"
}
actions {
block_download {
unscanned = true
active = true
}
}
}
}
resource "xray_watch" "test" {
name = "test-watch-name"
description = "test watch description"
resources {
type = "all-repos"
name = "All Repositories"
}
assigned_policies {
name = xray_policy.test.name
type = "security"
}
watch_recipients = ["test#example.com"]
}
I figured out it's based on the name of the resource type - so, that it doesn't start with artifactory makes a difference. What I'd like to know is the logic behind this lookup
[1]: https://github.com/ryndaniels/terraform-provider-xray
Terraform v0.13 introduced the idea of third-party providers that belong to other namespaces that are not controlled directly by HashiCorp, but to maximize backward compatibility with modules that were written for Terraform v0.12 and earlier there is a fallback behavior where Terraform will assume that any provider requirement not explicitly declared is aiming to use one of the official providers which now live in the "hashicorp" namespace in the registry, because for Terraform v0.12 and earlier third-party providers were not automatically installable at all.
When writing modules for Terraform v0.13 or later you should include explicit provider requirements to specify the full source addresses for each of the providers your module uses, like this:
terraform {
required_providers {
artifactory = {
source = "jfrog/artifactory"
}
xray = {
source = "ryndaniels/xray"
}
}
}
Unfortunately the "xray" provider you are trying to use here hasn't, at the time of my writing this, been published in the Terraform Registry. The source address ryndaniels/xray I used above is the address this provider would take if the author were to publish it to the registry as-is, because the Terraform Registry uses a methodical naming scheme to generate provider source addresess from GitHub repository addresses.
But unless that provider is later published in the registry, you'll need to install it on your local system manually in order for Terraform to find it and use it. To achieve that, refer to Implied Local Mirror Directories to see which directories Terraform searches for plugins on your platform, and then you can create the necessary directory structure for Terraform to find the provider.
For the sake of an example I'm going to use the $HOME/.terraform.d/plugins/ prefix that Terraform supports on Linux, but note that the paths are different on Windows and macOS and so you will need to adjust to a different path prefix on those operating systems:
$HOME/.terraform.d/plugins/registry.terraform.io/ryndaniels/xray/0.0.1/linux_amd64/terraform-provider-xray
A few more notes about the above:
The registry.terraform.io/ryndaniels/xray part is what Terraform matches with the source you set in your provider_requirements block. registry.terraform.io is the default hostname for a source address that doesn't include a hostname, so ryndaniels/xray is short for registry.terraform.io/ryndaniels/xray.
This particular provider doesn't have any tagged releases and so there isn't a specific version number to use. Because Terraform expects all providers to have a version number, I arbitrarily chose 0.0.1 as the version number in the path above. This will only matter if you write an explicit version argument in your module to constrain which versions are allowed.
I used linux_amd64 as the target platform here, continuing my example of using Linux-style mirror paths. You can find out which platform is correct for you by running terraform version, which on recent Terraform versions includes the name of the platform that your Terraform CLI executable was built for:
Terraform v0.14.4
on linux_amd64
On startup Terraform will scan all of the implied local mirror directories for your current platform and will note any providers it finds there, and assume that you intend to install those from your local filesystem rather than from the registry. Therefore as long as the directory structure is correct as above, terraform init will see that you have ryndaniels/xray installed locally and will use the copy from there rather than asking the Terraform Registry which versions are available for that provider.
If the provider author publishes this provider to the Terraform Registry at a later date, and they do so without renaming the repository or moving it into a different GitHub account, it should appear in the registry as ryndaniels/xray and thus terraform init will be able to automatically install it from there without any further modifications to your modules.
This was originating from Azure DevOps pipilene while running an analysis with SonarQube.
I tried to apply below steps but no luck.
NPM Task
npm install -g increase-memory-limit
Pipeline Variable
SONAR_SCANNER_OPTS = -Xmx4096m
Error Log
INFO: Sensor TypeScript analysis [javascript]
INFO: Using TypeScript at: 'D:\a\45\s\Source\RockyBrands.MODocuments\Presentation Tier\RockyBrands.MODocuments.Web.UI\node_modules'
INFO: Found 2 tsconfig.json file(s): [D:\a\45\s\Source\RockyBrands.MODocuments\Presentation Tier\RockyBrands.MODocuments.Web.UI\obj\Dev\Package\PackageTmp\tsconfig.json, D:\a\45\s\Source\RockyBrands.MODocuments\Presentation Tier\RockyBrands.MODocuments.Web.UI\tsconfig.json]
INFO: 23 source files to be analyzed
INFO: Analyzing 23 files using tsconfig: D:\a\45\s\Source\RockyBrands.MODocuments\Presentation Tier\RockyBrands.MODocuments.Web.UI\tsconfig.json
INFO: 0/23 files analyzed, current file: Source/RockyBrands.MODocuments/Presentation Tier/RockyBrands.MODocuments.Web.UI/app/Home/Payments/batch-details/batch.details.component.ts
INFO: 0/23 files analyzed, current file: Source/RockyBrands.MODocuments/Presentation Tier/RockyBrands.MODocuments.Web.UI/app/Home/Payments/batch-details/batch.details.component.ts
INFO: 0/23 files analyzed, current file: Source/RockyBrands.MODocuments/Presentation Tier/RockyBrands.MODocuments.Web.UI/app/Home/Payments/batch-details/batch.details.component.ts
INFO: 0/23 files analyzed, current file: Source/RockyBrands.MODocuments/Presentation Tier/RockyBrands.MODocuments.Web.UI/app/Home/Payments/batch-details/batch.details.component.ts
INFO: 0/23 files analyzed, current file: Source/RockyBrands.MODocuments/Presentation Tier/RockyBrands.MODocuments.Web.UI/app/Home/Payments/batch-details/batch.details.component.ts
**##[error]ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
##[error]ERROR: Failure during analysis, Node.js command to start eslint-bridge was: {NODE_PATH=D:\a\45\s\Source\RockyBrands.MODocuments\Presentation Tier\RockyBrands.MODocuments.Web.UI\node_modules} node D:\a\45\.sonarqube\out\.sonar\.sonartmp\eslint-bridge-bundle\package\bin\server 49855
java.lang.IllegalStateException: eslint-bridge is unresponsive**
at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.request(EslintBridgeServerImpl.java:202)
at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.analyzeTypeScript(EslintBridgeServerImpl.java:186)
ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory
You could try to added sonar.javascript.node.maxspace=8192 in the sonar-project.properties.
Besides, if you are using the private agent, you need to consider the RAM size of the machine where your private agent is located. You can try to reduce the number of files contained in tsconfig.json files.
And if you are using the hosted agent, you could try to increase the size of the memory using the command. (e.g node --max-old-space-size=16384./node_modules/#angular/cli/bin/ng build --prod). Please reference this similar thread : https://github.com/TrilonIO/aspnetcore-angular-universal/issues/736#issuecomment-517374967. According to codehippie1’s comment, it needs same changes in csproj and package.json.
My host is:
cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
The host setup was done as described here: http://docs.openstack.org/developer/tripleo-docs/environments/environments.html#virtual-environment up to the "Continue with Undercloud ..." step
The result:
sudo virsh list --all
Id Name State
----------------------------------------------------
3 baremetalbrbm_0 running
4 instack running
- baremetalbrbm_1 shut off
The undercloud setup was done as described here: http://docs.openstack.org/developer/tripleo-docs/installation/installation.html
The installation was attempted on the instack VM. Did the SSL setup as well.
Running
openstack undercloud install
fails with
+ puppet apply --detailed-exitcodes /etc/puppet/manifests/puppet-stack-config.pp Notice: Scope(Class[Tripleo::Firewall::Post]): At this stage, all network traffic is blocked. Warning: Scope(Class[Swift]): swift_hash_suffix has been deprecated and should be replaced with swift_hash_path_suffix, this will be removed Warning: Scope(Class[Nova::Keystone::Auth]): Note that service_name parameter default value will be changed to "Compute Service" (according future release. In case you use different value, please update your manifests accordingly. Warning: Scope(Class[Nova::Keystone::Auth]): Note that service_name_v3 parameter default value will be changed to "Compute Service v3" (acco in a future release. In case you use different value, please update your manifests accordingly. Warning: Scope(Class[Glance::Api]): The known_stores parameter is deprecated, use stores instead Warning: Scope(Class[Glance::Api]): default_store not provided, it will be automatically set to glance.store.filesystem.Store Warning: Scope(Class[Nova::Api]): In N cycle, enabled_apis will have to be an array of APIs to enable. Warning: Scope(Class[Neutron::Server]): identity_uri, auth_tenant, auth_user, auth_password, auth_region configuration options are deprecateted options Warning: Scope(Class[Neutron::Agents::Dhcp]): The dhcp_domain parameter is deprecated and will be removed in future releases Warning: Scope(Class[Heat]): Default value for rabbit_heartbeat_timeout_threshold parameter is different from OpenStack project defaults Warning: Scope(Class[Heat]): "admin_user", "admin_password", "admin_tenant_name" configuration options are deprecated in favor of auth_plugi Warning: Scope(Class[Nova::Network::Neutron]): neutron_auth_plugin parameter is deprecated and will be removed in a future release, use neut Error: Could not find class ::ironic::drivers::deploy for instack on node instack Error: Could not find class ::ironic::drivers::deploy for instack on node instack
+ rc=1
+ set -e
+ echo 'puppet apply exited with exit code 1' puppet apply exited with exit code 1
+ '[' 1 '!=' 2 -a 1 '!=' 0 ']'
+ exit 1 [2016-05-19 15:32:29,361] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/cot status 1]
[2016-05-19 15:32:29,362] (os-refresh-config) [ERROR] Aborting... Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 987, in install
_run_orc(instack_env) File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 866, in _run_orc
_run_live_command(args, instack_env, 'os-refresh-config') File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 444, in _run_live_command
raise RuntimeError('%s failed. See log for details.' % name) RuntimeError: os-refresh-config failed. See log for details. Command 'instack-install-undercloud' returned non-zero exit status 1
Tried to install the ironic api as described here http://docs.openstack.org/developer/ironic/deploy/install-guide.html although to my understanding, this should not be necessary, since the undercloud was not installed on a baremetal machine.
Same result.
Some hours of Puppet readings later, I went into the /etc/puppet/modules/ironic/manifests/drivers folder and found, to no surprise, that the deploy class was not there. Perhaps it should not have been needed? I copied it from https://github.com/openstack/puppet-ironic/blob/master/manifests/drivers/deploy.pp and it seems to have got past the error originally reported. Fingers crossed.
I'm trying to compile protocol buffers code using the maven protoc plugin and a protoc executable that I built inside Cygwin. I can't do this from Cygwin or from the Windows command line. Below is the output that I get when I run it in Windows, but the error is identical when running from Cygwin. I find this strange because if the issue was with path translation then I'd expect one of them to work. Is it possible that the fact that the executable was built with Cygwin's g++ could affect things? (To state the obvious, the directory in question does exist.)
Edit: I get the same error when I take maven out of the picture and just invoke protoc by hand.
Edit 2: I can fix this by invoking protoc by hand from Cygwin using relative or absolute paths (but tilde-expansion does not work). Invoking protoc by hand from Windows using relative or absolute paths continues to give the same error.
[DEBUG] (f) outputDirectory = c:\cygwin64\home\dan\code\server\protocol\target\generated-sources\protobuf\java
[DEBUG] (f) project = MavenProject: server:protocol:1.0-SNAPSHOT # c:\cygwin64\home\dan\code\server\protocol\pom.xml
[DEBUG] (f) protoSourceRoot = c:\cygwin64\home\dan\code\server\protocol\src\main\proto
[DEBUG] (f) protocPluginDirectory = c:\cygwin64\home\dan\code\server\protocol\target\protoc-plugins
[DEBUG] (f) remoteRepositories = [
id: central
url: https://repo.maven.apache.org/maven2
layout: default snapshots: [enabled => false, update => daily]
releases: [enabled => true, update => daily]
]
[DEBUG] (f) session = org.apache.maven.execution.MavenSession#24fb6a80
[DEBUG] (f) skip = false
[DEBUG] (f) staleMillis = 0
[DEBUG] (f) temporaryProtoFileDirectory = c:\cygwin64\home\dan\code\server\protocol\target\protoc-dependencies
[DEBUG] (f) writeDescriptorSet = false
[DEBUG] -- end configuration --
[WARNING] No 'protocExecutable' parameter is configured, using the default: 'protoc'
[DEBUG] Proto source root:
[DEBUG] c:\cygwin64\home\dan\code\server\protocol\src\main\proto
[DEBUG] [PROTOC] Executable:
[DEBUG] [PROTOC] protoc
[DEBUG] [PROTOC] Protobuf import paths:
[DEBUG] [PROTOC] c:\cygwin64\home\dan\code\server\protocol\src\main\proto [DEBUG] [PROTOC] Java output directory:
[DEBUG] [PROTOC] c:\cygwin64\home\dan\code\server\protocol\target\generated-sources\protobuf\java
[DEBUG] [PROTOC] Protobuf descriptors:
[DEBUG] [PROTOC] c:\cygwin64\home\dan\code\server\protocol\src\main\proto\message.proto
[DEBUG] [PROTOC] Command line options:
[DEBUG] [PROTOC]
--proto_path=c:\cygwin64\home\dan\code\server\protocol\src\main\proto
--java_out=c:\cygwin64\home\dan\code\server\protocol\target\generated-sources\protobuf\java
c:\cygwin64\home\dan\code\server\protocol\src\main\proto\message.proto
[INFO] Compiling 1 proto file(s) to c:\cygwin64\home\dan\code\server\protocol\target\generated-sources\protobuf\java
[ERROR] PROTOC FAILED: c: warning: directory does not exist. c:\cygwin64\home\dan\code\server\protocol\src\main\proto\message.proto: File does not reside within any path specified using --proto_path (or -I). You must specify a --proto_path which encompasses this file. Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).
Executables that you build using Cygwin will depend on the full Cygwin environment and will behave as Cygwin programs, regardless of how you execute them. That is, if you execute a Cygwin program from the non-Cygwin shell, it will still behave as a Cygwin program. Cygwin programs do not accept Windows-style paths that use backslashes an drive letters; you need to use e.g. /cygdrive/c/ instead of c:\.
In general, you should not attempt to use Cygwin-compiled command-line tools from a non-Cygwin shell. Instead, try building protoc using MSVC or MinGW, or use the pre-built Windows binaries that Google provides.