yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem@xxxxxxxxxx>]

** Tags added: api

** Changed in: nova
       Status: New => Triaged

** Changed in: nova
   Importance: Undecided => Medium

** Changed in: nova
     Assignee: (unassigned) => Matt Riedemann (mriedem)

** Also affects: nova/newton
   Importance: Undecided
       Status: New

** Also affects: nova/mitaka
   Importance: Undecided
       Status: New

** Also affects: nova/ocata
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1662699

Title:
  API documentation and behavior do not match for booting with attached
  volumes

Status in OpenStack Compute (nova):
  Triaged
Status in OpenStack Compute (nova) mitaka series:
  New
Status in OpenStack Compute (nova) newton series:
  New
Status in OpenStack Compute (nova) ocata series:
  New

Bug description:
  Description
  ===========

  The documentation for block device mapping in
  http://docs.openstack.org/developer/nova/block_device_mapping.html
  #block-device-mapping-v2 indicates that to attach a volume to a new
  instance without booting from that volume a boot_index value of None
  can be passed. Shade was doing this, and it works against some clouds
  (at least DreamHosts's iad2 cloud, "dreamcompute", which is running
  either mitaka or newton). It does not work against nova at least as of
  9ae5b2306b7a7cc9e77c77292256b13926920ead launched with devstack.

  Steps to reproduce
  ==================

  1. Run devstack.
  2. Download the downpour git repo from https://github.com/dhellmann/downpour
  3. Use the tiny.yml playbook in the demo directory to launch an instance (see the README for some setup instructions).

  Expected Result
  ===============

  One new instance named downpour-demo-tiny booted ephemeral with a new
  volume named downpour-demo-tiny attached to it.

  Actual Result
  =============

  Error message: Invalid input for field/attribute boot_index. Value:
  None. None is not of type 'integer'

  Additional Info
  ===============

  IRC logs from 7 Feb 2017 in #openstack-nova

  [Tue 05:29:35 PM]  <mordred>	mriedem: so - I've got this question about boot from volume
  [Tue 05:30:51 PM]  <mordred>	mriedem: http://developer.openstack.org/api-ref/compute/?expanded=create-server-detail#create-server says that block_device_mapping_v2.boot_index takes a string and also that None should be used for volumes not used as boot volumes
  [Tue 05:32:00 PM]  <mriedem>	was just packing up...
  [Tue 05:32:20 PM]  <mordred>	mriedem: but we just got an error "Invalid input for field/attribute boot_index. Value: None. None is not of type 'integer"
  [Tue 05:32:24 PM]  <mriedem>	mordred: http://docs.openstack.org/developer/nova/block_device_mapping.html might be helpful
  [Tue 05:32:33 PM]  <mordred>	mriedem: yup. it also says None is valid
  [Tue 05:34:01 PM]  <mriedem>	i feel like something was just recently changed in the json schema there, is this master?
  [Tue 05:34:17 PM]  <mordred>	dhellmann: you were doing master devstack?
  [Tue 05:34:30 PM]  <mordred>	mriedem: I think so yeah?
  [Tue 05:34:43 PM]  <dhellmann>	mordred : yes, master devstack (from a few hours ago)
  [Tue 05:34:45 PM] mordred	goes to look at json schema
  [Tue 05:34:51 PM]  <mriedem> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/block_device_mapping.py#L56
  [Tue 05:35:28 PM]  <mordred>	fantastic
  [Tue 05:36:06 PM]  <mriedem>	what's the image and dest type?
  [Tue 05:36:19 PM]  <mriedem>	source_type and destination_type i mean
  [Tue 05:37:01 PM]  <mriedem>	because https://github.com/openstack/nova/blob/master/nova/block_device.py#L198
  [Tue 05:37:02 PM]  <dhellmann>	it's a qcow2 ubuntu image
  [Tue 05:37:16 PM]  <mordred>	destination_type would be 'volume'
  [Tue 05:37:22 PM]  <mriedem>	and source_type is?
  [Tue 05:37:23 PM]  <mriedem>	image?
  [Tue 05:37:24 PM]  <dhellmann>	I want to boot it ephemeral  and attach a volume
  [Tue 05:37:47 PM]  <mordred>	yah- source_type also volume
  [Tue 05:38:01 PM]  <mriedem>	have you tried omitting boot_index
  [Tue 05:38:02 PM]  <mriedem>	?
  [Tue 05:38:05 PM]  <mordred>	yes. that works
  [Tue 05:38:12 PM]  <mordred>	as does providing -1 or '-1'
  [Tue 05:38:46 PM]  <mordred>	however, None worked in the past and is still referneced in the docs ... so maybe there's a bug somewhere, I'm just not sure what to file/write up
  [Tue 05:38:59 PM]  <mordred>	(we can make shade dtrt by omitting or using -1
  [Tue 05:39:14 PM]  <mriedem>	oomichi: Kevin_Zheng: gmann: alex_xu: do you remember anything recently related to this? ^
  [Tue 05:39:40 PM]  <mriedem>	https://review.openstack.org/#/c/410006/
  [Tue 05:40:50 PM]  <mriedem>	mordred: i wouldn't put a ton of faith in the api-ref docs on this one
  [Tue 05:40:57 PM]  <mordred>	mriedem: ok
  [Tue 05:41:03 PM]  <mriedem>	i'd be interested in knowing if it's different on like a liberty install
  [Tue 05:41:29 PM]  <mordred>	mriedem: None worked against dreamhost - whatever version is running there
  [Tue 05:41:43 PM]  <mriedem>	mordred: because my guess is the wording in the api-ref was pulled from http://docs.openstack.org/developer/nova/block_device_mapping.html and that's more about the actual object code in nova rather than the API
  [Tue 05:42:05 PM]  <mordred>	ah - k. so it's likely just a docs bug
  [Tue 05:42:06 PM]  <dhellmann>	dreamhost is either mitaka or newton
  [Tue 05:42:15 PM]  <mriedem>	i'd file a bug either way so we can investigate
  [Tue 05:42:27 PM]  <dhellmann>	I can do that
  [Tue 05:42:37 PM]  <mriedem>	plus, if the api is ok but the docs are wrong, we can use the bug to fix the docs
  [Tue 05:42:50 PM]  <mordred>	cool.
  [Tue 05:42:52 PM]  <mordred>	thanks dhellmann !
  [Tue 05:43:10 PM]  <dhellmann>	thanks, mordred & mriedem 
  [Tue 05:45:00 PM]  <mriedem>	also,
  [Tue 05:45:07 PM]  <mriedem>	i wonder if you were hitting a nova v2 vs v2.1 endpoint before...
  [Tue 05:45:11 PM]  <mriedem>	v2 didn't have schema validation
  [Tue 05:45:22 PM]  <mriedem>	mordred: dhellmann: ^
  [Tue 05:45:39 PM]  <mordred>	oh - it's entirely possible
  [Tue 05:46:06 PM]  <mordred>	shade is (currently) just piggybacking novaclient which grabs latest microversion aiui
  [Tue 05:46:12 PM]  <mordred>	I haven't gotten to doing explicit microversion code myself
  [Tue 05:46:29 PM]  <mordred>	(that'll be next month - expect plenty of questions from me)
  [Tue 05:47:02 PM]  <mriedem>	there is where the legacy v2 api bdm v2 stuff happened https://github.com/openstack/nova/blob/liberty-eol/nova/api/openstack/compute/legacy_v2/servers.py#L424
  [Tue 05:47:54 PM]  <mriedem>	which only checked boot_index here https://github.com/openstack/nova/blob/liberty-eol/nova/block_device.py#L201
  [Tue 05:48:00 PM]  <mriedem>	if source_type == 'image' and destination_type == 'local':
  [Tue 05:48:33 PM]  <mriedem>	and then that dict was probably turned into an object https://github.com/openstack/nova/blob/liberty-eol/nova/objects/block_device.py#L73
  [Tue 05:48:36 PM]  <mriedem>	where boot_index can be None
  [Tue 05:49:18 PM]  <mriedem>	the compute api did some validation here too https://github.com/openstack/nova/blob/liberty-eol/nova/compute/api.py#L1315
  [Tue 05:49:20 PM]  <mriedem>	on the object
  [Tue 05:49:22 PM]  <mriedem>	SO,
  [Tue 05:49:38 PM]  <mriedem>	i think it just means that the v2.1 API json schema validation regressed from the v2 API validation
  [Tue 05:49:56 PM]  <mriedem>	would be cool if you guys could confirm that it was working when you were talking to a v2 compute endpoint cloud vs v2.1
  [Tue 05:50:03 PM]  <mriedem>	but that'd be my professional opinion
  [Tue 05:50:09 PM]  <mriedem>	dr debug
  [Tue 05:51:06 PM]  <mriedem>	dhellmann: i've got to run but just throw ^ into the bug report and i'll check it out later when i'm home

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1662699/+subscriptions