Ask Your Question

jidar's profile - activity

2019-02-04 18:32:07 -0500 asked a question TripleO network_data.yaml contents not enforced

I'm attempting to deploy an overcloud using tripleo, during the deployment my ExternalNetCidr, ExternalAllocationPools, and ExternalInterfaceDefaultRoute are defined in network-environment.yaml and network_data.yaml. The values found in network-environment.yaml are the defaults like 10.0.0.0/24, the values found in network_data.yaml are from my environment. When I tried to only use the values found in network_data.yaml the deployment failed with the externalnet attempting to ping 10.0.0.1 on vlan 7.

Here is a snippet of my network_data.yaml

- name: External
  vip: true
  name_lower: external
  vlan: 7
  ip_subnet: '10.37.7.0/24'
  allocation_pools: [{'start': '10.37.7.4', 'end': '10.37.7.250'}]
  gateway_ip: '10.37.7.1'
  ipv6_subnet: '2001:db8:fd00:1000::/64'
  ipv6_allocation_pools: [{'start': '2001:db8:fd00:1000::10', 'end': '2001:db8:fd00:1000:ffff:ffff:ffff:fffe'}]
  gateway_ipv6: '2001:db8:fd00:1000::1'

And here is what my deploy command looks like:

openstack overcloud deploy --templates \
        -r /home/stack/templates/roles_data.yaml \
        -e /home/stack/templates/overcloud_images.yaml \
        -e /home/stack/templates/node-info.yaml \
        -e /home/stack/templates-rendered/environments/ceph-ansible/ceph-ansible.yaml \
        -e /home/stack/templates/ceph-config.yaml \
        -n /home/stack/templates/network_data.yaml \
        -e /home/stack/templates-rendered/environments/network-isolation.yaml \
        -e /home/stack/templates-rendered/environments/network-environment.yaml \
        -e /home/stack/templates-rendered/environments/net-bond-with-vlans.yaml \
        -e /home/stack/templates/custom-network-configuration.yaml \
        --ntp-server foo.com

/home/stack/templates-rendered is where I stuck the rendered templates from the following command:

./tools/process-templates.py -o ~/templates-rendered

network-environment.yaml was modified with the following values when deployments failed otherwise:

parameter_defaults:
  <snip>
  ExternalNetCidr: '10.37.7.0/24'
  ExternalAllocationPools: [{'start': '10.37.7.4', 'end': '10.37.7.250'}]
  ExternalInterfaceDefaultRoute: '10.37.7.1'
  <snip>

One curious thing I noticed is that my custom-network-configuration.yaml (shown below) defines the VLANs for all networks, and those vars were used (it seems in my case network_data.yaml is entirely ignored). But when I tried to also define CIDRs and Allocation pools it failed with the deployment reporting "these were defined but not used"

resource_registry:
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/bond-with-vlans/compute.yaml
  OS::TripleO::ControllerNoCeph::Net::SoftwareConfig: /home/stack/templates/bond-with-vlans/controller.yaml
  OS::TripleO::CephAll::Net::SoftwareConfig: /home/stack/templates/bond-with-vlans/ceph-storage.yaml
parameter_defaults:
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.168.24.1
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.168.24.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ['10.2.0.40', '10.2.0.41']
  NeutronExternalNetworkBridge: "''"
  BondInterfaceOvsOptions: "mode=802.3ad lacp=active"
  # setting this here because its required even though it's set in the network_data.yaml
  StorageNetworkVlanID: 4
  StorageMgmtNetworkVlanID: 3
  InternalApiNetworkVlanID: 2
  TenantNetworkVlanID: 5
  ExternalNetworkVlanID: 7
  ManagementNetworkVlanID: 1
2017-04-18 22:47:38 -0500 received badge  Famous Question (source)
2017-02-14 10:04:58 -0500 received badge  Famous Question (source)
2017-02-11 21:37:40 -0500 received badge  Notable Question (source)
2017-02-06 03:10:03 -0500 received badge  Popular Question (source)
2017-01-30 09:51:36 -0500 received badge  Notable Question (source)
2017-01-27 16:04:42 -0500 received badge  Popular Question (source)
2017-01-27 12:40:20 -0500 received badge  Scholar (source)
2017-01-27 12:40:02 -0500 commented answer Heat OS::Keystone::User return user name not just user id

This might be more heat specific, but is there any way for me to determine the data type or possible outputs in heat? For instance, get_attr: ... then show how do we know that there is a name in that? Regular show doesn't include name but {get_attr: [admin_user, show, name]} works...

2017-01-26 12:03:56 -0500 asked a question Heat OS::Keystone::User return user name not just user id

I'm attempting to create a user inside of a heat stack, give that user read access to a swift container and then build some servers that pull content out of the swift container. Seems simple enough, right?

The first issue arises when I try to build a curl GET against swift using the user id and password. For whatever reason OSP10 requires v2 keystone tokens to use swift. I suppose there is a chance I could use tempURLs here, but haven't followed up on that.

So here is how I pull down my token, and then list the contents of a container (and then download)

publicURL="http://<someURL>:8080/v1/AUTH_05c<etc>"

OUTPUT=$(curl -sS -d '
{ "auth":
  { "tenantName": "admin", 
    "passwordCredentials": 
      { "username": "foo-stackuser1", "password": "<somepassword>" }
  }
}' -H "Content-type: application/json" http://<someURL>:5000/v2.0/tokens | jq --raw-output '.access.token.id')

curl -X GET -i $publicURL/c1 -H "X-Auth-Token: ${OUTPUT}"

Keep in mind here, that the v2 api's don't let me use a userid for passwordCredentials v2 api found here

The heat stack that's generating the foo-stackuser1 looks like this,

heat_template_version: 2013-05-23

description: Sample Keystone User template

parameters:
  user_password:
    type: string
    description: Keystone user password

resources:
  admin_user:
    type: OS::Keystone::User
    properties:
      name: foo-stackuser1
      domain: default
      password: {get_param: user_password}
      default_project: admin
      roles:
        - role: _member_
          project: admin
outputs:
  admin_user_id:
    value: {get_resource: admin_user}

The thing is, I'm really not interested in hard-setting the foo-stackuser and I'd prefer to nix the name: field entirely. However, I can't find a way to get the return value of admin_user to include the username (only the user id).

2017-01-19 02:26:27 -0500 answered a question OS::Heat::SoftwareDeployment and Image Requirements aka Diskimage builder

This was the fix, apparently epel just isn't enabled by default even when the system needs packages that are only available in epel

$ git diff
diff --git a/elements/centos7/element-deps b/elements/centos7/element-deps
index c6e5925..18aa763 100644
--- a/elements/centos7/element-deps
+++ b/elements/centos7/element-deps
@@ -4,3 +4,4 @@ redhat-common
 rpm-distro
 source-repositories
 yum
+epel

I'll also note that I was able to discover this upon looking at the yum history of the resulting image from diskimage-builder, it had the following for one of my entries:

# yum history info 3
Loaded plugins: fastestmirror
Transaction ID : 3
Begin time     : Wed Jan 18 19:32:15 2017
Begin rpmdb    : 311:8175ca00eacccb2c0528a9636a1dd2e69ef2317a
End time       :            19:32:31 2017 (16 seconds)
End rpmdb      : 370:3e2b9b5644ed8a7e915fac3288e92ef758b44f9c
User           : Cloud User <centos>
Return-Code    : Success
Command Line   : -v -y install make automake gcc gcc-c++ kernel-devel git traceroute zlib-devel lsof jq libxslt-devel ccache which tcpdump python-devel libxml2-devel

You can see right there it's attempting to install jq and later it will attempt to install puppet but can't, because there's no place to find it. This becomes more apparently when you really take a fine look at the log for diskimage-builder.

After a little more inspection we can see that epel was removed as a dependency for diskimage-builder a few months ago, found here: https://git.openstack.org/cgit/openst... which obviously breaks stuff now-a-days.

Edit: I'll note that you don't need to modify the elements/centos7/elements-deps file at all, just tack on epel to the diskimage-builder command ie: diskimage-builder/bin/disk-image-create vm {...} epel {...}

2017-01-18 14:09:48 -0500 received badge  Editor (source)
2017-01-18 14:06:43 -0500 asked a question OS::Heat::SoftwareDeployment and Image Requirements aka Diskimage builder

I'm attempting to launch a simple example template found in the Openstack/heat-templates repo, "example-puppet-template.yaml" Example Script Template

What I find is that the tools required to run this are not found inside the default cloud-image for CentOS-7.

I note that the instructions for prepairing a image with both the git repo's "test image" (Found Here) and the Software Deployment "Custom Image Script" (Found Here) both depend on using disk-image-builder.

The Script for diskimage-builder looks like the following, with CentOS7 and puppet:

# Clone the required repositories. Some of these are also available
# via pypi or as distro packages.
git clone https://git.openstack.org/openstack/diskimage-builder.git
git clone https://git.openstack.org/openstack/tripleo-image-elements.git
git clone https://git.openstack.org/openstack/heat-templates.git

# Required by diskimage-builder to discover element collections
export ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements

# The base operating system element(s) provided by the diskimage-builder
# elements collection. Other values which may work include:
# centos7, debian, opensuse, rhel, rhel7, or ubuntu
export BASE_ELEMENTS="centos7 selinux-permissive"

# Install and configure the os-collect-config agent to poll the metadata
# server (heat service or zaqar message queue and so on) for configuration
# changes to execute
export AGENT_ELEMENTS="os-collect-config os-refresh-config os-apply-config"


# heat-config installs an os-refresh-config script which will invoke the
# appropriate hook to perform configuration. The element heat-config-script
# installs a hook to perform configuration with shell scripts
export DEPLOYMENT_BASE_ELEMENTS="heat-config heat-config-script"

# Install a hook for any other chosen configuration tool(s).
# Elements which install hooks include:
# heat-config-cfn-init, heat-config-puppet, or heat-config-salt
export DEPLOYMENT_TOOL="heat-config-puppet"

# The name of the qcow2 image to create, and the name of the image
# uploaded to the OpenStack image registry.
export IMAGE_NAME=centos-7-software-config

# Create the image
diskimage-builder/bin/disk-image-create vm $BASE_ELEMENTS $AGENT_ELEMENTS \
     $DEPLOYMENT_BASE_ELEMENTS $DEPLOYMENT_TOOL -o $IMAGE_NAME.qcow2

# Upload the image, assuming valid credentials are already sourced
glance image-create --disk-format qcow2 --container-format bare \
    --name $IMAGE_NAME < $IMAGE_NAME.qcow2

The example from docs.openstack.org uses virtualenv (which seems entirely unnecessary?) Is there a way to disable that?

So when launching a stack based off the above image created there's a few things that go wrong, the first and foremost is that the application jq is required by os-collect-config to report back to heat (I think?) and looks like the following in the logs:

dib-run-parts Wed Jan 18 19:56:03 UTC 2017 55-heat-config completed
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 ----------------------- PROFILING -----------------------
dib-run-parts Wed Jan 18 19:56:03 UTC 2017
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 Target: configure.d
dib-run-parts Wed Jan 18 19:56:03 UTC 2017
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 Script                                     Seconds
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 ---------------------------------------  ----------
dib-run-parts Wed Jan 18 19:56:03 UTC 2017
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 20-os-apply-config                            0.186
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 55-heat-config                                0.084
dib-run-parts Wed Jan 18 19:56:03 UTC 2017
dib-run-parts Wed Jan 18 19:56:03 UTC 2017 --------------------- END PROFILING ...
(more)
2016-02-18 15:31:53 -0500 received badge  Teacher (source)
2016-02-16 01:41:50 -0500 answered a question How to bond provisioning NICs in Redhat OpenStack Platform 7?

From the redhat docs found here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html-single/Director_Installation_and_Usage/index.html#sect-Using_the_Native_VLAN_on_a_Trunked_Interface (https://access.redhat.com/documentati...)

You can configure the native vlan to use the trunked interface for your deployment. Obviously, the native vlan will need to be the Provision interface.

The director uses this network traffic type to deploy new nodes over PXE boot and orchestrate the installation of OpenStack Platform on the Overcloud bare metal servers.  This network is predefined before the installation of the Undercloud.

.

F.4. USING THE NATIVE VLAN ON A TRUNKED INTERFACE

If a trunked interface or bond has a network on the native VLAN, the IP addresses are assigned directly to the bridge and there will be no VLAN interface.
For example, if the External network is on the native VLAN, a bonded configuration looks like this:

network_config:
  - type: ovs_bridge
    name: {get_input: bridge_name}
    dns_servers: {get_param: DnsServers}
    addresses:
      - ip_netmask: {get_param: ExternalIpSubnet}
    routes:
      - ip_netmask: 0.0.0.0/0
        next_hop: {get_param: ExternalInterfaceDefaultRoute}
    members:
      - type: ovs_bond
        name: bond1
        ovs_options: {get_param: BondInterfaceOvsOptions}
        members:
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4
2016-01-12 00:07:51 -0500 received badge  Enthusiast
2015-12-15 14:08:56 -0500 answered a question volume wwn

Nova exposes the WWPN of the HBA it uses to attach LUNs, it does this like the following: https://review.openstack.org/#/c/19992/ and os-brick can be used to review that information: http://lists.openstack.org/pipermail/openstack-announce/2015-September/000581.html (http://lists.openstack.org/pipermail/...) However I am unable to determine the entirely of the way one would use API calls or Client calls to determine this information and I've also been unable to find this info in logs.

2015-10-17 14:55:21 -0500 received badge  Supporter (source)
2015-10-17 12:51:00 -0500 commented question Heat stack create failed

I'm seeing a similar error in the OSP7 from Redhat - where I see the error is basically in the same way, except the missing Puppet class is tripleo::packages, not found anywhere in the modulepath. I have yet to figure out how to solve this.