Openstack image oem_id does not match coreos-metadata provider #1917

Closed
kostasns opened this Issue Apr 15, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@kostasns

Issue Report

Bug

When using coreos images for openstack default oem_id in /usr/share/oem/grub.cfg is set to openstack
Providing Ingition template with dynamic data causes coreos-metadata.service to fail with invalid provider error message.

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1353.4.0
VERSION_ID=1353.4.0
BUILD_ID=2017-03-31-0211
PRETTY_NAME="Container Linux by CoreOS 1353.4.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Environment

Cisco Metacloud (Openstack). I believe we are currently using Icehouse release.

Expected Behavior

$ journalctl -t coreos-metadata
-- Logs begin at Sat 2017-04-15 16:06:42 UTC, end at Sat 2017-04-15 16:27:29 UTC. --
Apr 15 16:42:51 localhost coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/instance-id": Attempt #1
Apr 15 16:42:51 localhost coreos-metadata[630]: Failed to fetch: Get http://169.254.169.254/latest/meta-data/instance-id: dial tcp 169.254.169.254:80: connec
Apr 15 16:42:52 localhost coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/instance-id": Attempt #2
Apr 15 16:42:52 host-10-105-16-149 coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/local-ipv4": Attempt #1
Apr 15 16:42:52 host-10-105-16-149 coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/public-ipv4": Attempt #1
Apr 15 16:42:52 host-10-105-16-149 coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/hostname": Attempt #1
Apr 15 16:42:52 host-10-105-16-149 coreos-metadata[630]: Fetching "http://169.254.169.254/latest/meta-data/public-keys": Attempt #1

Actual Behavior

$ journalctl -t coreos-metadata
-- Logs begin at Sat 2017-04-15 16:06:42 UTC, end at Sat 2017-04-15 16:27:29 UTC. --
Apr 15 16:06:55 localhost coreos-metadata[763]: invalid provider "openstack"

Reproduction Steps

  1. Use template
{
"ignition": {
  "version": "2.0.0",
  "config": {}
},
"storage": {
  "files": [
    {
      "filesystem": "root",
      "path": "/etc/coreos/update.conf",
      "contents": {
        "source": "data:,GROUP%3Dstable%0AREBOOT_STRATEGY%3Detcd-lock",
        "verification": {}
      },
      "mode": 420,
      "user": {},
      "group": {}
    }
  ]
},
"systemd": {
  "units": [
    {
      "name": "etcd-member.service",
      "enable": true,
      "dropins": [
        {
          "name": "20-clct-etcd-member.conf",
          "contents": "[Unit]\nRequires=coreos-metadata.service\nAfter=coreos-metadata.service\n\n[Service]\nEnvironmentFile=/run/metadata/coreos\nEnvironment=\"ETCD_IMAGE_TAG=v3.1.0\"\nExecStart=\nExecStart=/usr/lib/coreos/etcd-wrapper $ETCD_OPTS \\\n  --name=\"${COREOS_OPENSTACK_HOSTNAME}\" \\\n  --listen-peer-urls=\"http://${COREOS_OPENSTACK_IPV4_LOCAL}:2380\" \\\n  --listen-client-urls=\"http://0.0.0.0:2379\" \\\n  --initial-advertise-peer-urls=\"http://${COREOS_OPENSTACK_IPV4_LOCAL}:2380\" \\\n  --advertise-client-urls=\"http://${COREOS_OPENSTACK_IPV4_LOCAL}:2379\" \\\n  --discovery=\"https://discovery.etcd.io/token""
        }
      ]
    }
  ]
},
"networkd": {},
"passwd": {
  "users": [
    {
      "name": "core",
      "sshAuthorizedKeys": [
        "ssh-rsa SomeKey"
      ]
    }
  ]
}
}
  1. Boot the instance
nova boot --user-data ./ingition_template.ign --image coreos-image  --flavor your-favourite-flavor --security-groups default coreos
  1. Check the logs

Other Information

Sort of a workaround found in #1413 .
Changing entry in /usr/share/oem/grub.cfg to set oem_id="openstack-metadata" and running sgdisk --disk-guid 00000000-0000-0000-0000-000000000001 will make coreos-metada happy with the provider after reboot.

@crawford

This comment has been minimized.

Show comment
Hide comment
@crawford

crawford Apr 17, 2017

Member

This is mostly expected behavior. The reason coreos-metadata cannot use the cmdline in the case of OpenStack is due to it needing to support both config-drive and the network metadata service. Container Linux Configs are designed to abstract this problem for you (though investigating this shows that ct doesn't properly invoke coreos-metadata).

Member

crawford commented Apr 17, 2017

This is mostly expected behavior. The reason coreos-metadata cannot use the cmdline in the case of OpenStack is due to it needing to support both config-drive and the network metadata service. Container Linux Configs are designed to abstract this problem for you (though investigating this shows that ct doesn't properly invoke coreos-metadata).

@dgonyeo

This comment has been minimized.

Show comment
Hide comment
@dgonyeo

dgonyeo Apr 19, 2017

This should be fixed in CoreOS at the next releases, for any users of the config transpiler (direct ignition configs will need a little extra logic).

dgonyeo commented Apr 19, 2017

This should be fixed in CoreOS at the next releases, for any users of the config transpiler (direct ignition configs will need a little extra logic).

@kostasns

This comment has been minimized.

Show comment
Hide comment
@kostasns

kostasns Apr 20, 2017

Perfect!! Thank you for quick turnaround.

Perfect!! Thank you for quick turnaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment