API documentation and behavior do not match for booting with attached volumes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Matt Riedemann | ||
Mitaka |
Fix Released
|
Medium
|
Matt Riedemann | ||
Newton |
Fix Committed
|
Medium
|
Matt Riedemann | ||
Ocata |
Fix Committed
|
Medium
|
Matt Riedemann |
Bug Description
Description
===========
The documentation for block device mapping in http://
Steps to reproduce
==================
1. Run devstack.
2. Download the downpour git repo from https:/
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://
[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://
[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:/
[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:/
[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:/
[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://
[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:/
[Tue 05:47:54 PM] <mriedem> which only checked boot_index here https:/
[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:/
[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:/
[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
tags: | added: api |
Changed in nova: | |
status: | New → Triaged |
importance: | Undecided → Medium |
assignee: | nobody → Matt Riedemann (mriedem) |
Changing shade to pass -1, '-1', or to leave the boot_index value out entirely all makes it work. See https:/ /review. openstack. org/430465