| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-25 | |||
| 15:57:21 | bauzas | heh, in France we don't have ceiling fans, unless you wanna have a saloon | |
| 15:57:39 | bauzas | or you're about your 90s | |
| 15:57:50 | bauzas | we prefer sweating | |
| 15:58:02 | sean-k-mooney | bauzas: we dont have them in ireland normally either | |
| 15:58:17 | sean-k-mooney | bauzas: i just didnt want to by an ac systme yet | |
| 15:58:30 | bauzas | yeah me too | |
| 16:00:43 | sean-k-mooney | im currently planning to wait to get ac untill i also deside if im getting solar next year | |
| 16:12:39 | jsuchome | :q | |
| 16:12:57 | jsuchome | ouch, wrong window :-) | |
| 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 | 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: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: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 | openstack | Launchpad bug 1854053 in OpenStack Compute (nova) "_add_tenant_access silently ignores 403" [Undecided,In progress] - Assigned to Harshavardhan Metla (harsha24) | |
| 17:10:24 | sean-k-mooney | so the discription of https://bugs.launchpad.net/nova/+bug/1854053 is not clear | |
| 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 | |