Ask Your Question

dlbewley's profile - activity

2019-11-02 21:12:22 -0600 received badge  Famous Question (source)
2019-10-20 22:07:22 -0600 asked a question Why does openstack complete fail when python-tripleoclient is installed?

After installing python-tripleoclient, I have difficulty running openstack complete. I see the following errors.

Many of this warning:

2019-10-20 19:54:51.048 18772 DEBUG osc_lib.clientmanager [-] No service catalog is_service_available /home/dlbewley/src/openstack-client/pyenv-test.13/lib/python2.7/site-packages/osc_lib/clientmanager.py:229

And a total failure here until I place an entry into my /etc/hosts:

2019-10-20 19:50:19.804 14620 ERROR openstack [-] No entry for tofu.ctlplane in /etc/hosts: ImageUploaderException: No entry for tofu.ctlplane in /etc/hosts
2019-10-20 19:50:19.805 14620 INFO osc_lib.shell [-] END return value: 1

My requirements.txt FWIW:

python-openstackclient==3.14.1
python-cinderclient
python-designateclient
python-glanceclient
gnocchiclient
python-ironic-inspector-client
python-keystoneclient
python-neutronclient
python-novaclient
oslo.log
python-heatclient
python-ironicclient
python-tripleoclient
shade

Is it unreasonable to expect to use openstack overcloud commands from a host other than the director? (eg. _node delete_) oslo.log python-heatclient python-ironicclient python-tripleoclient shade

2019-06-26 07:51:24 -0600 received badge  Famous Question (source)
2019-05-20 19:13:44 -0600 received badge  Notable Question (source)
2019-04-22 04:06:01 -0600 received badge  Popular Question (source)
2019-04-19 17:37:02 -0600 received badge  Notable Question (source)
2019-04-19 13:39:43 -0600 received badge  Scholar (source)
2019-04-19 13:38:41 -0600 commented answer Use a Heat condition to exclude item from list

I guess this creates an empty mime blob but works.

server_init:
    type: OS::Heat::MultipartMime
    properties:
      parts:
        - config: ...
        - if: [ playbook_included, config: { get_attr: [playbook_runner, resource.playbook_runner] }, config: '' ]
2019-04-18 07:35:52 -0600 received badge  Student (source)
2019-04-17 16:54:23 -0600 asked a question Use a Heat condition to exclude item from list

Can I use a condition to exclude a part from the list of configs ina MultipartMime resource?

GOAL, If parameter 'playbook_repo' is empty string then: do not create certain resources, and do not include certain SoftwareConfig in MultipartMime user-data.

I'm trying to make my template flexible and reusable, but maybe I'm trying to be too clever.

  • Custom resources snippet follows:
  resource_registry:
    Custom::OS::Heat::SoftwareConfig::Playbook-Runner: ../user-data/playbook-runner.yaml
    Custom::OS::Nova::Keypair::NSA: ssh/group/nsa.yaml
    Custom::OS::Nova::Server::With-Volume: server/with-volume.yaml
  • Heat template test-servers.yaml follows:
  heat_template_version: queens
  parameters:
    ...
  resources:
    servers:
      type: OS::Heat::ResourceGroup
      depends_on:
        - router_internal_interface
      properties:
        count: { get_param: instance_count }
        resource_def:
          type: Custom::OS::Nova::Server::With-Volume
          properties:
            ...
  • Custom::OS::Nova::Server::With-Volume: server/with-volume.yaml snippet follows:
  heat_template_version: queens
  parameters:
    ...
    playbook_repo:
      type: string
      label: Playbook git repo
      description: Playbook to checkout and run via cloud-init user_data
      default: ''

  conditions:
    playbook_included:
      not:
        equals:
        - get_param: playbook_repo
        - ''

  resources:
    ssh_keys_admins:
      type: Custom::OS::Nova::Keypair::NSA

    # GOAL optionally do not create this:
    playbook_waitcondition_handle:
      type: OS::Heat::WaitConditionHandle
      condition: playbook_included

    # GOAL optionally do not create this:
    playbook_waitcondition:
      type: OS::Heat::WaitCondition
      condition: playbook_included
      properties:
        handle: { get_resource: playbook_waitcondition_handle }
        count: 1
        timeout: 600

    # GOAL optionally do not create this:
    playbook_runner:
      type: Custom::OS::Heat::SoftwareConfig::Playbook-Runner
      condition: playbook_included
      properties:
        playbook_notify_heat: { get_attr: [ playbook_waitcondition_handle, 'curl_cli' ] }

    server_init:
      type: OS::Heat::MultipartMime
      properties:
        parts:
        - config: { get_attr: [ssh_keys_admins, resource.cloud_config_ssh] }
        # GOAL optionally do not include the following part:
        - config: { get_attr: [playbook_runner, resource.playbook_runner] }

    instance:
      type: OS::Nova::Server
      properties:
        name: { get_param: instance_name }
        image: { get_param: image }
        flavor: { get_param: flavor }
        key_name: { get_param: key }
        networks:
          - port: { get_resource: server_port }
        user_data_format: RAW
        user_data:
          get_resource: server_init
2019-04-09 10:41:30 -0600 received badge  Popular Question (source)
2019-04-03 14:55:22 -0600 answered a question Are /dev/disk/by-id symlinks unreliable?

Not entirely sure what the root cause is, but my workaround is to trigger a udev event when the symlink is not found. This is my userdata script. Pass it through str_replace like this:

heat resource

  volume_provisioner:
    type: OS::Heat::SoftwareConfig
    properties:
      group: ungrouped
      config:
        str_replace:
          template: { get_file: ../user-data/format-cinder-volume.sh }
          params:
            $volume_id: { get_resource: data_volume }
            $volume_name: { get_attr: [data_volume, display_name] }
            $volume_mount: { get_param: data_drive_path }

format-cinder-vollume.sh

#!/bin/bash -x

# volume UUID
VOLUME_ID="$volume_id"
# nova passes truncated volume ID
VOLUME_DEV="/dev/disk/by-id/virtio-$(echo $VOLUME_ID | cut -c -20)"
# will get truncated in filesystem label
VOLUME_LABEL="$volume_name"
# path to mount data volume at
MOUNT_POINT="$volume_mount"
FILESYSTEM_TYPE="$volume_fileystem"
FILESYSTEM_TYPE=${FILESYSTEM_TYPE:-xfs}

if [[ ! -L "$VOLUME_DEV" ]]; then
    echo "triggering udev to create by-id symlink"
    /sbin/udevadm trigger \
        --action=change \
        --type=devices \
        --subsystem-match=block \
        --verbose
fi

if [[ ! -L "$VOLUME_DEV" ]]; then
    echo "volume device $VOLUME_DEV not found"
    exit 1
fi

# use Cinder volume ID as filesystem UUID and as much volume name that will fit in label
if [ "$FILESYSTEM_TYPE" == "ext4" ]; then
    mkfs.ext4 "$VOLUME_DEV" -U "$VOLUME_ID" -L "$(echo $VOLUME_LABEL | cut -c -16)"
elif [ "$FILESYSTEM_TYPE" == "xfs" ]; then
    mkfs.xfs "$VOLUME_DEV" -m "uuid=$VOLUME_ID" -L "$(echo $VOLUME_LABEL | cut -c -12)"
fi

if [ -n "$MOUNT_POINT" ]; then
  mkdir -p "$MOUNT_POINT"
  echo "UUID=${VOLUME_ID} ${MOUNT_POINT} ${FILESYSTEM_TYPE} defaults 0 1" >> /etc/fstab
  mount "$MOUNT_POINT"
fi
2019-04-02 14:57:11 -0600 answered a question How to make sure Heat creates router before floating ip association?

Resource dependencies can be created using depends_on. https://docs.openstack.org/heat/queens/template_guide/hot_spec.html#hot-spec-resources-dependencies (Doc).

By causing the floating IP to depend on the router's internal interface, the resources will be created in appropriate order.

Example:

resources:
  private_network_r:
    type: OS::Neutron::Net
    properties:
      name: { get_param: private_network }

  private_subnet_r:
    type: OS::Neutron::Subnet
    properties:
      name: {get_param: private_network }
      network_id: { get_resource: private_network_r }
      cidr: { get_param: subnet_cidr }
      dns_nameservers: [ "1.1.1.1" ]
      ip_version: 4

  internal_router:
    type: OS::Neutron::Router
    properties:
      external_gateway_info:
        network: { get_param: public_network }

  server_port:
    type: OS::Neutron::Port
    properties:
      network: { get_resource: private_network_r }
      security_groups: ["default", { get_resource: security_group } ]

  floating_ip:
    type: OS::Neutron::FloatingIP
    depends_on:
      - internal_interface
    properties:
      floating_network: { get_param: public_network }
      port_id: { get_resource: server_port }
2019-04-01 22:59:25 -0600 commented question How to make sure Heat creates router before floating ip association?

I discovered a couple things. Most importantly, I had some cruft in my template that was leading to ambiguous private network selection.

Also, I can avoid using an FloatingIPAssociation and just supply the port as a parameter to the FloatingIP resource.

2019-04-01 19:33:03 -0600 asked a question How to make sure Heat creates router before floating ip association?

How can I ensure the OS::Neutron::Router and OS::Neutron::RouterInterface resources are created before the OS::Neutron::FloatingIPAssociation resource in my stack?

Most times when I create this stack, I run into the following error. This indicates to me that the assocation is being made before the router has been (fully?) provisioned.

Clearly the router has an interface on the subnet 7e31 and the external network 9762. In fact, I can make the association by hand after the stack create fails.

$ openstack stack failures list ceph-test
ceph-test.floating_ip_assoc:
  resource_type: OS::Neutron::FloatingIPAssociation
  physical_resource_id:
  status: CREATE_FAILED
  status_reason: |
    NotFound: resources.floating_ip_assoc: External network 9762bfe2-443e-496f-ad92-3a650f4939f4 is not reachable from subnet 7e31c131-ca04-4b39-85ff-55c8f29d599f.  Therefore, cannot associate Port 06f02924-d398-484a-a5c5-7b4f5c56ab2f with a Floating IP.
    Neutron server returns request_ids: ['req-ba89d2e8-b15b-41b3-be6a-62a027195436']

$ openstack router show ceph-test-internal_router-ozwaclszqvgw -c external_gateway_info -c interfaces_info -f yaml
external_gateway_info: '{"network_id": "9762bfe2-443e-496f-ad92-3a650f4939f4", "enable_snat":
  true, "external_fixed_ips": [{"subnet_id": "0e81c736-a670-44ba-a026-d8df6fddae38",
  "ip_address": "10.37.179.14"}]}'
interfaces_info: '[{"port_id": "3e8aec07-de10-474a-9332-22e16b1c2e52", "ip_address":
  "192.168.1.1", "subnet_id": "7e31c131-ca04-4b39-85ff-55c8f29d599f"}]'

$ openstack stack resource list ceph-test
+------------------------+-------------------------------------------------------------------------------------+------------------------------------+-----------------+----------------------+
| resource_name          | physical_resource_id                                                                | resource_type                      | resource_status | updated_time         |
+------------------------+-------------------------------------------------------------------------------------+------------------------------------+-----------------+----------------------+
| server_init            | 32abadf5-bb34-45bc-97b8-d8ecf19a370f                                                | OS::Heat::MultipartMime            | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| new_net                | 5cf51a37-636d-4876-be1d-81323468ca6e                                                | OS::Neutron::Net                   | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| volume_provisioner     | d11a1979-0ed9-4694-8871-a4b8669a568c                                                | OS::Heat::SoftwareConfig           | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| resolv_conf            | b0ba5bb9-7e2f-41d5-874a-4535e6a440a5                                                | OS::Heat::CloudConfig              | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| internal_interface     | 4aa28b58-4768-4cc1-b8af-d767b0ef7c06:subnet_id=7e31c131-ca04-4b39-85ff-55c8f29d599f | OS::Neutron::RouterInterface       | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| floating_ip            | 73f35c25-1c6a-4c9d-8cf2-f7cdc1bb283e                                                | OS::Neutron::FloatingIP            | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| floating_ip_assoc      |                                                                                     | OS::Neutron::FloatingIPAssociation | CREATE_FAILED   | 2019-04-02T00:06:29Z |
| instance               | 17f04c07-60b6-4525-bb56-7457e37a1e58                                                | OS::Nova::Server                   | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| new_subnet             | 7e31c131-ca04-4b39-85ff-55c8f29d599f                                                | OS::Neutron::Subnet                | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| internal_router        | 4aa28b58-4768-4cc1-b8af-d767b0ef7c06                                                | OS::Neutron::Router                | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| data_volume_attachment |                                                                                     | OS::Cinder::VolumeAttachment       | INIT_COMPLETE   | 2019-04-02T00:06:29Z |
| security_group         | e2e02382-edeb-4e3c-bf7a-0629348127c9                                                | OS::Neutron::SecurityGroup         | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| playbook_runner        | 338ba07e-c059-4be0-9366-5c22068dc175                                                | OS::Heat::SoftwareConfig           | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| port                   | 06f02924-d398-484a-a5c5-7b4f5c56ab2f                                                | OS::Neutron::Port                  | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
| data_volume            | 0be35af5-8003-4740-8845-c1a2b3fc35e2                                                | OS::Cinder::Volume                 | CREATE_COMPLETE | 2019-04-02T00:06:29Z |
+------------------------+-------------------------------------------------------------------------------------+------------------------------------+-----------------+----------------------+
2019-01-08 23:03:12 -0600 received badge  Supporter (source)
2019-01-08 23:03:10 -0600 commented answer Heat: The resource type could not be found.

That worked for me. I find that very surprising.

Just found it is mentioned here: https://docs.openstack.org/heat/rocky/template_guide/environment.html (https://docs.openstack.org/heat/rocky...)

The template file extension must be .yaml or .template, or it will not be treated as a custom template resource.
2018-12-31 18:58:38 -0600 received badge  Famous Question (source)
2018-09-04 09:06:02 -0600 received badge  Notable Question (source)
2018-09-01 06:29:41 -0600 received badge  Popular Question (source)
2018-08-31 10:53:02 -0600 received badge  Enthusiast
2018-08-30 17:39:51 -0600 asked a question How to install ML2 driver in containerized control plane?

With Newton we were able to pip install networking-generic-switch ML2 plugin on our controllers, and successfully automate the switches involved in our overcloud baremetal provisioning.

pip install http://tarballs.openstack.org/networking-generic-switch/networking-generic-switch-stable-newton.tar.gz

How do I install this or any other ML2 driver with the containerized control plane used in Queens (OSP13)?

If I must add it to the container image, does it go in both the ironic_conductor and neutron_api image?

2018-03-22 02:13:45 -0600 received badge  Notable Question (source)
2018-03-22 00:04:10 -0600 received badge  Popular Question (source)
2018-03-21 10:04:30 -0600 answered a question How do I pip install openstack-client version matching OSP release?

I wound up brute forcing the issue by checking deps on the RPM and trying to manually pip install each one. I ultimately ended up with a requirements.txt like this:

python-openstackclient==3.8.1
python-cinderclient==1.11.0
python-designateclient
python-glanceclient==2.6.0
python-keystoneclient==3.10.0
python-neutronclient==6.1.1
python-novaclient==7.1.2
oslo.log
python-heatclient
python-ironicclient
shade
2018-03-14 10:30:30 -0600 commented answer ERROR: 'unicode' object has no attribute 'get' Heat

I just hit the same problem with OSP 11, Ocata.

2018-03-14 10:30:29 -0600 asked a question How do I pip install openstack-client version matching OSP release?

I am pip installing openstack-client to perform operations from a Mac and I'm experiencing trouble with version mismatches with my OSP 11 cloud.

I've discovered some differences in nova command parameters, specifically around floating IP options when comparing to my RPM install of the client.

My requirements.txt:

python-openstackclient==3.8.1
python-heatclient
python-ironicclient
shade

Mac with pip:

$ openstack --version
openstack 3.8.1
$ nova --version
10.1.0

Linux with RPM:

$ rpm -q python-openstackclient
python-openstackclient-3.8.1-1.el7ost.noarch
$ openstack --version
openstack 3.8.1
$ nova --version
7.1.2

Is it as brute force as finding all the versions of the python-foo RPMs required by python-openstackclient, finding the module versions of all those, and pinning them in my requirements.txt?

Is there perhaps a shortcut to finding the versions of all the python clients associated with a given OSP release?