[OpenStack-Infra] Problems setting up my own OpenStack Infrastructure

Bernd Bausch berndbausch at gmail.com
Thu Apr 5 00:41:36 UTC 2018


Clark,

looks like I have my first task :)

I will look into fixing the nodepool-builder problems below. Three of
them, if I understand this right:

  * Puppet doesn't create the //var/log/nodepool///images /log directory
  * The command /service //nodepool-builder//start /seems to//start a
    nodepool process that immediately aborts/
    /
  * The nodepool element /openstack-repos/ is not found

Let me see how far I can get on my own. Thanks much for the offer to
tutor me on the IRC; I will watch out for you in my morning. Our time
difference is between 13 hours (EDT) and 16 hours (PDT) if you are
located in the continental US, i.e. 7pm EDT is 8am next day here in Japan.

Bernd.

On 4/5/2018 3:45 AM, Clark Boylan wrote:
> On Tue, Apr 3, 2018, at 10:45 PM, Bernd Bausch wrote:
>> Lenny,
>>
>> thanks, these instructions are a bit more robust and easier to
>> understand than [2].
>>
>> One details stands out for me: They make it clear that Ubuntu 14 is
>> required. A few Puppet modules, in particular Etherpad used as an
>> example in [2], assume Upstart. I don't know if Upstart is available in
>> Xenialor recent non-Ubuntu distros, but it's definitely not there by
>> default.
> Correct, we are in the process of migrating to 16.04 (Xenial) currently which is taking some time in the cases where upstart was used or assumed. Generally we've not removed upstart support when we switch to supporting systemd so 14.04 should also work in cases where we now deploy to 16.04.
>
>> I did find a few places that could be improved or may even be incorrect.
>> How can I formally submit suggestions and bugs in the OpenStack-Infra
>> documentation?
>>
>> Here they are:
>>
>> - First, install_puppet.sh is downloaded and executed, then
>> system-config is cloned.
>>   Since system-config contains install_puppet.sh, it would be more
>> efficient to clone, then
>>   install Puppet.
> I think this is a good suggestion. Would you be willing to push a change for that improvement? The documentation lives at https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/doc/source/third_party_ci.rst. Feel free to ping me for reviews if you do push some changes.
>
>> - Configuration of /etc/puppet/environments/common.yaml is not quite
>> trivial. Perhaps a few
>>   examples would help people like me.
> ++ It may be best if a user of the third party deployment tooling contributes this as it will most likely reflect reality if they do rather than someone trying to come up with example examples. That said something is better than nothing if we have a volunteer to push that.
>
>> - The instructions first install the log server, then the CI server. The
>> log server is tested
>>   by uploading a file to Jenkins, which runs on the CI server and is not
>> yet available at that
>>   point.
>>
>> - The Jenkins installation fails since a prerequisite can't be found:
>>
>>    The following packages have unmet dependencies:
>>     jenkins : Depends: default-jre-headless (>= 2:1.8) but it is not
>> going to be installed or
>>               java8-runtime-headless but it is not installable
>>
>> - I was unable to start nodepool-builder with "service nodepool-builder
>> start".
>>   First, nodepool-builder aborted since it is configured to log to a
>> file under
>>   /var/log/nodepool/images/, which doesn't exist.
>>   After fixing this manually, the service command is successful, but no
>>   nodepool-builder process is running. I didn't find out why and just
>> started
>>   the daemon manually.
> The previous two items are likely bugs in the puppet itself that will have to be addressed by updating resource dependencies for Jenkins and creating the images log dir for nodepool-builder. If you would like to work on fixing these I am happy to help. Creating the images log dir should be straightforward if we want to start there. Maybe we can coordinate on IRC as it will be a bit more realtime as far as walking through that.
>
>> - Attempting an image build fails with a stacktrace containing:
>>
>>     diskimage_builder.element_dependencies.MissingElementException:
>>     Element 'openstack-repos' not found
> This element should come from https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/doc/source/third_party_ci.rst which I thought the puppeting would clone to the correct location for you. This one has me a bit stumped. Happy to help debug it more real time if you like, but to start look in your /etc/nodepool/nodepool.yaml file for an elements-dir config item. That directory (something like /etc/nodepool/elements) should contain a directory called openstack-repos if things were set up properly. Working back from why that isn't happening is probably the best way to debug this error.
>
>> This is how far I got for the moment.
>>
>> Bernd
>>
>> On 4/1/2018 2:21 PM, Lenny Berkhovsky wrote:
>>> Hello Bernd,
>>> There is also a Third Party CI page[1] that may assist you
>>>
>>> [1] https://docs.openstack.org/infra/openstackci/third_party_ci.html
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180405/489a2f02/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180405/489a2f02/attachment.sig>


More information about the OpenStack-Infra mailing list