Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-07
22:37:02 dhellmann it's a qcow2 ubuntu image
22:37:16 mordred destination_type would be 'volume'
22:37:22 mriedem and source_type is?
22:37:23 mriedem image?
22:37:25 dhellmann I want to boot it ephemeral and attach a volume
22:37:47 mordred yah- source_type also volume
22:38:01 mriedem have you tried omitting boot_index
22:38:02 mriedem ?
22:38:05 mordred yes. that works
22:38:12 mordred as does providing -1 or '-1'
22:38:46 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
22:38:59 mordred (we can make shade dtrt by omitting or using -1
22:39:14 mriedem oomichi: Kevin_Zheng: gmann: alex_xu: do you remember anything recently related to this? ^
22:39:40 mriedem https://review.openstack.org/#/c/410006/
22:40:50 mriedem mordred: i wouldn't put a ton of faith in the api-ref docs on this one
22:40:57 mordred mriedem: ok
22:41:01 openstackgerrit Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in resource_class https://review.openstack.org/430463
22:41:04 mriedem i'd be interested in knowing if it's different on like a liberty install
22:41:29 mordred mriedem: None worked against dreamhost - whatever version is running there
22:41:43 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
22:42:05 mordred ah - k. so it's likely just a docs bug
22:42:06 dhellmann dreamhost is either mitaka or newton
22:42:15 mriedem i'd file a bug either way so we can investigate
22:42:27 dhellmann I can do that
22:42:37 mriedem plus, if the api is ok but the docs are wrong, we can use the bug to fix the docs
22:42:51 mordred cool.
22:42:52 mordred thanks dhellmann !
22:43:05 openstackgerrit Alex Szarka proposed openstack/nova master: Changed maximum code complexity to 30 https://review.openstack.org/351176
22:43:10 dhellmann thanks, mordred & mriedem
22:45:00 mriedem also,
22:45:07 mriedem i wonder if you were hitting a nova v2 vs v2.1 endpoint before...
22:45:11 mriedem v2 didn't have schema validation
22:45:22 mriedem mordred: dhellmann: ^
22:45:39 mordred oh - it's entirely possible
22:46:06 mordred shade is (currently) just piggybacking novaclient which grabs latest microversion aiui
22:46:12 mordred I haven't gotten to doing explicit microversion code myself
22:46:29 mordred (that'll be next month - expect plenty of questions from me)
22:47:02 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
22:47:54 mriedem which only checked boot_index here https://github.com/openstack/nova/blob/liberty-eol/nova/block_device.py#L201
22:48:00 mriedem if source_type == 'image' and destination_type == 'local':
22:48:33 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
22:48:36 mriedem where boot_index can be None
22:49:18 mriedem the compute api did some validation here too https://github.com/openstack/nova/blob/liberty-eol/nova/compute/api.py#L1315
22:49:20 mriedem on the object
22:49:22 mriedem SO,
22:49:38 mriedem i think it just means that the v2.1 API json schema validation regressed from the v2 API validation
22:49:56 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
22:50:03 mriedem but that'd be my professional opinion
22:50:09 mriedem dr debug
22:51:06 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
22:51:15 dhellmann mriedem : ok
22:51:36 dhellmann mriedem : I am currently working my way through the rather long instructions for filing a nova bug
22:56:09 openstack Launchpad bug 1662699 in OpenStack Compute (nova) "API documentation and behavior do not match for booting with attached volumes" [Undecided,New]
22:56:09 dhellmann mriedem: https://bugs.launchpad.net/nova/+bug/1662699
23:02:31 Daviey dhellmann: I *think* that might have been the same issue i saw when using Packer with volumes. Had to change Packer's usage with Volumes
23:02:40 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - servers.py https://review.openstack.org/359861
23:02:52 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - manager.py https://review.openstack.org/359868
23:02:59 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - linux_net.py https://review.openstack.org/359871
23:03:21 dhellmann Daviey : yeah, it's a behavior change but it's not clear if it's a bug and if so where (code or docs)
23:11:16 openstackgerrit Alex Szarka proposed openstack/nova master: Transform instance-exists notification https://review.openstack.org/403660
23:35:38 openstackgerrit Dan Smith proposed openstack/nova master: Add an update_cell command to nova-manage https://review.openstack.org/430354
#openstack-nova - 2017-02-08
00:37:13 alex_xu pkholkin: :( but thanks for your contribution, and good luck in your new adventure! :)
01:00:44 openstackgerrit Vivek Agrawal proposed openstack/nova-specs master: Spec for libvirt driver extension for Veritas HyperScale https://review.openstack.org/430488
01:18:17 Kevin_Zheng mriedem: I have one concerning destination type here also https://review.openstack.org/#/c/402372/
01:40:04 openstackgerrit Vladik Romanovsky proposed openstack/nova master: tests: fix vlan test type from int to str https://review.openstack.org/430496
01:42:38 mriedem Kevin_Zheng: i left a comment in your change
01:42:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow None for block_device_mapping_v2.boot_index https://review.openstack.org/430497
01:42:56 mriedem mordred: dhellmann: alex_xu: oomichi: gmann: Kevin_Zheng: fix for the boot_index=None thing ^
01:43:09 Kevin_Zheng thanks
01:44:44 Kevin_Zheng mriedem: yeah, my initial plan was to fail
01:45:13 Kevin_Zheng mriedem: so should we make destination_type checked in schema or in python?
01:46:46 mriedem Kevin_Zheng: i'm not sure, it would be good to understand what cases, if any, that destination_type could be None
01:48:13 Kevin_Zheng mriedem: Ok, I understand, I will try more cases
01:48:50 mriedem Kevin_Zheng: oh i see your defaults are copied from what novaclient does
01:48:56 mriedem i didn't know that novaclient did that
01:48:57 mriedem odd
01:50:00 mriedem mdbooth might have ideas on this
01:50:03 Kevin_Zheng mriedem: but at least with source_type=volume and snapshot, with a None destination_type a bdm will be create and nothing in cinder will happen
01:50:57 gmann mriedem: yes, you are right, its v2.1 schema validation made it to stop None
01:51:43 gmann and we have to fix this all the way till mitaka ?
01:52:25 Kevin_Zheng I think thats also what I did, but suggested by Kevin L Mitchell
01:52:57 mriedem Kevin_Zheng: yeah i see you made that change in novaclient
01:53:08 mriedem i don't think nova (or the client) should guess
01:53:35 mriedem gmann: it's been regressed since probably we added that schema
01:53:42 mriedem gmann: so i plan on backporting it as far as possible
01:53:56 gmann yea :(
01:54:08 mriedem i believe we deprecated the v2 api in liberty
01:54:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow None for block_device_mapping_v2.boot_index https://review.openstack.org/430497
01:54:48 Kevin_Zheng I think we have to dig deeper with the destination_type one, because at least for some cases, it will leave a bdm but nothing else
01:55:31 mriedem Kevin_Zheng: with source_type in 'volume' or 'snapshot' then yes i agree we can default destination_type to 'volume'
01:55:36 mriedem since that's the only dest type for those source types
01:55:48 mriedem but source_type in image or blank it's not that simple
01:56:10 huanxie Hi all, could you help review my patch to fix live migration problems with XenServer https://review.openstack.org/#/c/424428/, thanks a lot~
01:56:53 Kevin_Zheng hmm, but if the user don't provide destination_type, maybe a default one is reasonable
01:57:45 mriedem Kevin_Zheng: that would be a change in the api behavior
01:58:36 Kevin_Zheng I will check what soure=image and blank goes with None
01:58:52 mriedem now if source_type=blank and guest_format is not None, you could maybe assume destination_type=local
02:00:08 Kevin_Zheng should we cleanup client also?
02:02:18 mriedem Kevin_Zheng: probably, at least for the source_type case
02:02:30 mriedem i mean, source_type in ('image', 'blank')

Earlier   Later