Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-25
16:31:40 openstackgerrit sean mooney proposed openstack/nova stable/train: Silence amqp heartbeat warning https://review.opendev.org/728057
16:32:07 k_mouza good afternoon all! quick question please. I have a plain and simple openstack stein environment and I'm integrating a Ceph cluster with it. Is there a clean way of moving all the existing VMs (that reside on the hypervisors' local disks) to Ceph? I've tried draining a single hypervisor, configuring it to use Ceph, but then the migration of VMs to it fails because it can't find that VM's disk (it's expecting it in Ceph already I think).
16:32:42 k_mouza I could snapshot everything and re-spin it up of course, but was wondering if there's anything faster than that. Thanks a lot! :)
16:33:50 sean-k-mooney k_mouza: are you trying to change the image backend
16:34:02 sean-k-mooney e.g. form flat/qcow to rbd
16:35:13 sean-k-mooney i dont thik we support migration between hosts with different image backends at least i dont think we test it if we do
16:36:13 sean-k-mooney k_mouza: shelve and unshelve might be one way to do it but i have never tried that
16:37:02 sean-k-mooney k_mouza: the nova irc meeting is happeing right now so maybe someoen else will have a suggestion when that is over
16:39:05 josephillips hey sean-k-mooney do you know if is posible change the HW property created by a image on a running vm?
16:44:57 k_mouza sean-k-mooney: hmm, no, I haven't changed the image backend of the running VM. I will try shelving the VM before migrating it as well to see if that helps.
16:49:13 k_mouza sean-k-mooney: shelving and then un-shelving the VM did the trick! It picked the 2nd hypervisor and created the image in Ceph without issues. Thanks a lot for the tip!
16:50:03 k_mouza Now in order to control which hypervisor it's unshelved to, will need to disable and enable the corresponding nova-compute services?
16:51:43 sean-k-mooney josephillips: only via a rebuild currently
16:52:03 josephillips rebuild wil destroy the data?
16:52:08 josephillips or change mac address?
16:52:19 sean-k-mooney josephillips: i have been suggesting we should add a new api action to allow recreating a vm preseving its disk and other resouces but updating the flavor and image metadata
16:52:29 sean-k-mooney josephillips: it wont change mac
16:52:42 sean-k-mooney it will destroy the root disk
16:52:54 sean-k-mooney and i dont think its supported for boot form volume
16:53:10 sean-k-mooney josephillips: if you cant use rebuild today you have to do a db edit and then hard reboot
16:53:41 josephillips is what i belive that modifying novadb
16:53:44 sean-k-mooney k_mouza: i meant on the host but glad shelviing worked
16:53:45 josephillips will be the remedy
16:54:02 sean-k-mooney josephillips: what are you trying to change out of interest?
16:54:26 sean-k-mooney if i end up propsoinbg a spec for the recreate action i might include it as a use case
16:54:27 josephillips ok hw_disk_bus=scsi
16:54:37 josephillips works well fro new deployments
16:54:41 josephillips for new deployment
16:55:07 sean-k-mooney ah ok provided you are using disk lables or uuids to mount your files systems in fstabls changin the buss should be fine
16:55:17 sean-k-mooney if its a windows guest it might be unhappy
16:55:28 josephillips yeah i know
16:55:43 josephillips probably should be need to replace grub.conf
16:55:53 josephillips but is a change that we already know we have todo
16:56:03 sean-k-mooney normally grub.conf usses uuids by default
16:56:06 sean-k-mooney so it should be ok
16:56:22 josephillips just we need replace for the running instances
16:56:34 sean-k-mooney we stoped using /dev/sd* names quite a whgile a go in grub by default
16:57:05 josephillips yeah but these cloud still have /dev/s..
16:57:06 josephillips lol
16:57:20 josephillips so this hw metadata should be in novadb right
17:00:28 sean-k-mooney josephillips: ya its the instance_system_metadata table i think
17:00:31 sean-k-mooney in the cell db
17:00:56 sean-k-mooney i think you prefix the metadata key wiht img_ or iamge_
17:01:15 sean-k-mooney basicaly that is where we store the cache copy of the iamge metadata
17:01:16 gibi sean-k-mooney: I have to leave now but if akhil-g joins then from my perspective it is OK to add a service up check in the rebuild codepath
17:01:31 sean-k-mooney gibi: ya i was thinking the same
17:01:35 gibi cool
17:01:53 gibi I will not it in the bug tomorrow if nothing else happnes during my night
17:01:58 gibi I will note it
17:02:13 sean-k-mooney by the way i jsut want to highligh this downstream bug for people interested in libvirt https://bugzilla.redhat.com/show_bug.cgi?id=1847924
17:02:13 openstack bugzilla.redhat.com bug 1847924 in openstack-nova "[SRIOV - Cold Migration] some issues after a server with a VF port is migrated" [High,New] - Assigned to smooney
17:02:42 sean-k-mooney we have a issue with how libvirt report data related to deivces and how its caching works
17:02:58 sean-k-mooney i will file an upstream bug for this
17:03:28 sean-k-mooney but while i think its an libvirt issue i think we also should work around it in nova until libvirt can be fixed
17:04:02 sean-k-mooney so if people see error message like "ibvirt.libvirtError: Node device not found: no node device with matching name 'net_enp7s0f3v1_ea_60_77_1f_21_50'"
17:04:16 sean-k-mooney in the nova compute log its this issue
17:08:58 sean-k-mooney harsha24: so there is not really a concept of an admin project
17:09:27 sean-k-mooney we can create a projet in keysonte and call it admin but htat does not change the permission in any way as far as i know
17:10:03 sean-k-mooney the roles/permmision are assoicated with the user not the porject
17:10:24 sean-k-mooney so the discription of https://bugs.launchpad.net/nova/+bug/1854053 is not clear
17:10:24 openstack Launchpad bug 1854053 in OpenStack Compute (nova) "_add_tenant_access silently ignores 403" [Undecided,In progress] - Assigned to Harshavardhan Metla (harsha24)
17:10:49 harsha24 so is the bug invalid
17:11:58 sean-k-mooney if you give a user the the admin role they shoudl be able to add teh project to a private flavor in my view and then other user in the prorject with "member" but not "admin" should be able to use it
17:12:25 sean-k-mooney so i think that bug is invaild yes
17:13:06 sean-k-mooney mriedem: traiged it however so i guess he taught it was valid i need to read the irclogs to see why as the context is not directly in the bug
17:13:18 sean-k-mooney harsha24: ^
17:13:46 sean-k-mooney harsha24: im sure he had a good reason to make it traiged and therefor valid
17:15:45 sean-k-mooney ok so this i a more subtel bug then it seams looking at http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-11-26.log.html#t2019-11-26T16:20:24
17:16:00 harsha24 I have gone through that irclogs and i have changed the code part which returns true in https://review.opendev.org/#/c/735068/
17:16:35 sean-k-mooney you mean which raises failure
17:16:42 harsha24 yeah
17:16:58 sean-k-mooney you did not update the comment by the way
17:17:27 sean-k-mooney you are not defaulting to "it's ok" anymore you are raising a failure
17:19:05 harsha24 how to get pass the zuul code review
17:20:05 sean-k-mooney harsha24: are you asking how to get teh code merged
17:20:22 sean-k-mooney harsha24: if so then you need to get peopel to be interested and review the patch
17:21:13 sean-k-mooney an alternitive way to do this would be for nova to use its admin permisison to check if the porject exits in this case
17:21:29 sean-k-mooney im trying to see if that was discussed and discarded before
17:22:07 harsha24 sean-k-mooney you did not update the comment by the way
17:22:36 harsha24 which comment are you mentioning here
17:22:39 stephenfin gmann would be a good person to review that patch also
17:22:51 sean-k-mooney harsha24: https://review.opendev.org/#/c/735068/3/nova/api/openstack/identity.py
17:23:01 sean-k-mooney harsha24: i left a comment on the code review
17:23:04 harsha24 is it ok with the failures in zuul pipeline checks
17:24:07 sean-k-mooney harsha24: you have unit test failure you need to update nova.tests.unit.test_identity.IdentityValidationTest.test_unknown_id
17:24:10 sean-k-mooney for the new behavior
17:24:30 sean-k-mooney so the py36 and py38 failures are correct
17:25:04 sean-k-mooney its the same issue for lower constratins and cover job
17:25:13 harsha24 where do I need to update the test case
17:25:17 sean-k-mooney the grenade job failure are likely not related to your change
17:25:43 harsha24 okay
17:26:05 sean-k-mooney here https://github.com/openstack/nova/blob/master/nova/tests/unit/test_identity.py#L85-L94
17:26:25 gmann stephenfin: ack, will do after rbac meeting
17:26:59 sean-k-mooney harsha24: you need to replace the self.assertTrue( with self.assertRaises like the test_no_project one above it
17:27:52 harsha24 ok got it Thank you
17:28:31 harsha24 can you review this too https://review.opendev.org/#/c/737215/
17:32:51 sean-k-mooney harsha24: i added stephenfin to https://review.opendev.org/#/c/737215/1 ill take a look. moving it out of the rdo section into a common section seams resonable but i have not looked to see if we shoudl cross freference it in the old section or not and if its correct in context
17:33:45 sean-k-mooney harsha24: so i wont review it fully now but ill review later
17:33:45 harsha24 okay
17:34:04 sean-k-mooney im not realy shure how that closes https://bugs.launchpad.net/nova/+bug/1700999

Earlier   Later