Re: [openstack-dev] [nova] Block Device Mapping is Invalid error
Hello once more!
It turned out that proper body arg will be generated if you add
another --block-device param with source=image like this:
nova boot qwe --flavor vm1 --image cent-os7-vm --block-device
id=0af1f5a8-8172-4936-a958-90486759d598,source=volume,dest=volume,device=sdb,bootindex=1
--block-device
id=1b6fd7a7-16b6-4053-91d1-41a625d6b185,source=image,device=sda,bootindex=0
Can you clarify please if API was changed since Juno release. Is it
redundant since we specify --image param?
On 03/16/2015 06:55 PM, aburluka wrote:
Hello Nova!
I'd like to ask community to help me with some unclear things. I'm
currently working on adding persistent storage support into a
parallels driver.
I'm trying to start VM.
nova boot test-vm --flavor m1.medium --image centos-vm-32 --nic
net-id=c3f40e33-d535-4217-916b-1450b8cd3987 --block-device
id=26b7b917-2794-452a-95e5-2efb2ca6e32d,bus=sata,source=volume,bootindex=1
Got an error:
ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for
the instance and image/block device mapping combination is not valid.
(HTTP 400) (Request-ID: req-454a512c-c9c0-4f01-a4c8-dd0df0c2e052)
nova/api/openstack/compute/servers.py
def create(self, req, body)
Has such body arg:
{u'server':
{u'name': u'test-vm',
u'imageRef': u'b9349d54-6fd3-4c09-94f5-8d1d5c5ada5c',
u'block_device_mapping_v2': [{u'disk_bus': u'sata',
u'source_type': u'volume',
u'boot_index': u'1',
u'uuid':
u'26b7b917-2794-452a-95e5-2efb2ca6e32d'}],
u'flavorRef': u'3',
u'max_count': 1,
u'min_count': 1,
u'networks': [{u'uuid': u'c3f40e33-d535-4217-916b-1450b8cd3987'}],
'scheduler_hints': {}
}
}
Such block device mapping leads to bad boot indexes list.
I've tried to watch this argument while executing similiar command
with kvm hypervisor on Juno RDO and get something like in body:
{u'server': {u'name': u'test-vm',
u'imageRef': u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc',
u'block_device_mapping_v2': [{u'source_type': u'image',
u'destination_type': u'local',
u'boot_index': 0,
u'delete_on_termination': True,
u'uuid':
u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc'},
{u'disk_bus': u'sata',
u'source_type': u'volume',
u'boot_index': u'1',
u'uuid':
u'57a27723-65a6-472d-a67d-a551d7dc8405'}],
u'flavorRef': u'3',
u'max_count': 1,
u'min_count': 1,
'scheduler_hints': {}}}
Can you answer next questions please:
1) Does the first version miss an 'source_type': 'image' arg?
2) Where should and image block_device be added to this arg? Does it
come from novaclient or is it added by some callback or decorator?
Looking forward for your help!
--
Regards,
Alexander Burluka
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Block Device Mapping is Invalid error
Hello Nova!
I'd like to ask community to help me with some unclear things. I'm
currently working on adding persistent storage support into a parallels
driver.
I'm trying to start VM.
nova boot test-vm --flavor m1.medium --image centos-vm-32 --nic
net-id=c3f40e33-d535-4217-916b-1450b8cd3987 --block-device
id=26b7b917-2794-452a-95e5-2efb2ca6e32d,bus=sata,source=volume,bootindex=1
Got an error:
ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for
the instance and image/block device mapping combination is not valid.
(HTTP 400) (Request-ID: req-454a512c-c9c0-4f01-a4c8-dd0df0c2e052)
nova/api/openstack/compute/servers.py
def create(self, req, body)
Has such body arg:
{u'server':
{u'name': u'test-vm',
u'imageRef': u'b9349d54-6fd3-4c09-94f5-8d1d5c5ada5c',
u'block_device_mapping_v2': [{u'disk_bus': u'sata',
u'source_type': u'volume',
u'boot_index': u'1',
u'uuid':
u'26b7b917-2794-452a-95e5-2efb2ca6e32d'}],
u'flavorRef': u'3',
u'max_count': 1,
u'min_count': 1,
u'networks': [{u'uuid': u'c3f40e33-d535-4217-916b-1450b8cd3987'}],
'scheduler_hints': {}
}
}
Such block device mapping leads to bad boot indexes list.
I've tried to watch this argument while executing similiar command with
kvm hypervisor on Juno RDO and get something like in body:
{u'server': {u'name': u'test-vm',
u'imageRef': u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc',
u'block_device_mapping_v2': [{u'source_type': u'image',
u'destination_type': u'local',
u'boot_index': 0,
u'delete_on_termination': True,
u'uuid':
u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc'},
{u'disk_bus': u'sata',
u'source_type': u'volume',
u'boot_index': u'1',
u'uuid':
u'57a27723-65a6-472d-a67d-a551d7dc8405'}],
u'flavorRef': u'3',
u'max_count': 1,
u'min_count': 1,
'scheduler_hints': {}}}
Can you answer next questions please:
1) Does the first version miss an 'source_type': 'image' arg?
2) Where should and image block_device be added to this arg? Does it
come from novaclient or is it added by some callback or decorator?
Looking forward for your help!
--
Regards,
Alexander Burluka
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Feature Freeze Exception for Add config drive support for PCS containers
Hi, There are some questions about FFE policy that are not obvious for me as a newbie. Last version of my change was submitted at February, 11th, and has not been changed since that date. That change has +2 from Daniel and +1 from Garry Kotton and +1 from Pavel Kholkin. The only thing I needed to merge this code was the last +2. Today I've got a comment from Michael Still who said that merge deadline has expired. Can you please clarify, does this mean that this FFE was not accepted? Or should I wait a for further core review? Anyway, is there any chance to merge this code in Kilo release? Change is ready and does not have any objections except expired deadline note from Michael. Looking forward for your comments On 02/12/2015 04:26 PM, Daniel P. Berrange wrote: On Wed, Feb 11, 2015 at 03:28:49PM +0300, aburluka wrote: Hello, I'd like to request a feature freeze exception for the change [1] This change implements configuration drive support in Parallels containers. It does not change existing Nova behaviour. It's a last patch in parallels series, that implements blueprint pcs-support [2]. Previous patches of that blueprint were merged. So it's the last one to implement initial Parallels Cloud Server support in Nova compute driver. This change was reviewed by Daniel Berrange and Garry Kotton. I am looking forward for your decision about considering this changes for a feature freeze exception I'm happy to sponsor this, given that it lets us complete the intended level of support for parallels in Kilo. It does touch a bit of shared code but the changes at straightforward and should not cause regression in other drivers. Regards, Daniel -- Regards, Alexander Burluka __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Feature Freeze Exception for Add config drive support for PCS containers
Thank you so much for your help, Daniel On 02/16/2015 02:57 PM, Daniel P. Berrange wrote: On Mon, Feb 16, 2015 at 02:53:08PM +0300, aburluka wrote: Hi, There are some questions about FFE policy that are not obvious for me as a newbie. Last version of my change was submitted at February, 11th, and has not been changed since that date. That change has +2 from Daniel and +1 from Garry Kotton and +1 from Pavel Kholkin. The only thing I needed to merge this code was the last +2. Today I've got a comment from Michael Still who said that merge deadline has expired. Can you please clarify, does this mean that this FFE was not accepted? Or should I wait a for further core review? Anyway, is there any chance to merge this code in Kilo release? Change is ready and does not have any objections except expired deadline note from Michael. It would be better if the Nova core reviewers all replied to the FFE mails to say whether they support them or not, but it seems most have been ignoring all the emailed FFE requests :-( None the less there is a meeting today to finalize which FFEs will be approved. Regards, Daniel -- Regards, Alexander Burluka __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Feature Freeze Exception for Add config drive support for PCS containers
Hello, I'd like to request a feature freeze exception for the change [1] This change implements configuration drive support in Parallels containers. It does not change existing Nova behaviour. It's a last patch in parallels series, that implements blueprint pcs-support [2]. Previous patches of that blueprint were merged. So it's the last one to implement initial Parallels Cloud Server support in Nova compute driver. This change was reviewed by Daniel Berrange and Garry Kotton. I am looking forward for your decision about considering this changes for a feature freeze exception Thanks a lot! [1] https://review.openstack.org/#/c/149253/ [2] https://blueprints.launchpad.net/nova/+spec/pcs-support -- Regards, Alexander Burluka __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
