-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect value of project_config_repo in install_master.sh? #23
Comments
Hi SidBB, I don't think that is correct. project-config-repo should point to a git url. |
Hi rasselin, Yes, I'm using the new project-config layout. And yes, I can point it to a git URL instead of the local clone of that URL. My point is that it should point to my os-ext-testing-data repo because puppet expects my config files to be in there. But right now, according to line 131 of install_master.sh, it's pointing to the os-ext-testing repo (not data) which means puppet can't find any config files in it and throws errors. |
Just to clarify, I was able to fix the problem by fixing line 131. I only opened this issue to let you know. All I did was change line 131 to: zuul_args+="project_config_repo => '$DATA_PATH', " I guess using $data_repo_uri instead of $DATA_PATH would work just as well. I could send you a pull request instead, if you prefer. |
HI SidBB, Ok, your are correct, the else clause is using an invalid default value. In the meantime, I suggest you export PROJECT_CONFIG to avoid that code path. I'll look for a fix. If you'd like to do a pull request, I'm fine with that too. But it should be a git url. if [[ -n $PROJECT_CONFIG ]]; then |
Thanks. I'm pretty new to this whole thing and I don't fully understand the whole system-config and project-config architecture, so I'd rather not send you a pull request and break something. :) I'll use your suggestion and just export a PROJECT_CONFIG variable. Just to clarify ... am I correct in understanding that it should point to my custom data repository and not the default |
No worries. So there's a lot of historical baggage here. System-config used to host many of the puppet modules and openstack specific configurations. Puppet modules have since been split out to their own modules. [1], and the openstack configurations also in [2]. The idea of project-config is that all deployment specific configurations should go there, and you can simply select which one to use. This creates a very nice separation between the reusable code (puppet modules) and configurations (openstack, wiki-media, yours and mine). This repo previously used its own -data repo to host configurations. It was very similar to the project-config repo, so I recently restructured it to follow the project-config layout so that it can use the new reusable puppet modules in [3], which is part of this spec to create a common-ci solution [4]. So yes, you should use your own, but don't hesitate to reference the openstack-infra version if you're looking for a good source of examples. [1] http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-modules.html |
When I ran install_master.sh, the final "puppet apply" led to a few errors similar to this:
Error: /Stage[main]/Zuul::Server/File[/etc/zuul/layout]: Could not evaluate: Could not retrieve information from environment production source(s) file:/etc/project-config/zuul
I investigated and found that my /etc/project-config did not contain any of the config files. Instead, it contained the tree of your os-ext-testing repo.
It looks like it's due to a mistake on line 131 of install_master.sh. You've set project_config_repo to $OSEXT_REPO. I think it should be $DATA_PATH. I made that change in my local copy and it seemed to work.
The text was updated successfully, but these errors were encountered: