Earlier  
Posted Nick Remark
#openstack-nova - 2020-09-24
12:14:38 sean-k-mooney the package customisation is not that bad but it used to not work well behind proxies
12:14:39 kashyap - First, on quickness: it uses minimal kickstart for RPM-based, and similar for Debian-based
12:14:46 kashyap It can't get quicker than what the mirrors allow
12:14:51 sean-k-mooney so it was a pain to get working behind the intel firewall
12:15:42 kashyap - Second, the "docs" are quite readable too (very few open source tools can claim that): https://libguestfs.org/virt-builder.1.html
12:15:57 kashyap For Fedora users, I wrote this dead-simple guide some years ago - https://developer.fedoraproject.org/tools/virt-builder/about.html
12:16:25 sean-k-mooney i can take a look but i have read the docs and i dont find them that useful
12:16:44 sean-k-mooney i tried virt builder before dib
12:17:04 sean-k-mooney i only tried dib after i could not get it to do what i wanted
12:17:17 kashyap sean-k-mooney: User management is also easy:
12:17:18 kashyap chage -d 0 stack
12:17:18 kashyap useradd -m -p "" -G wheel stack
12:17:18 kashyap # Create the user account.
12:17:18 kashyap virt-builder [...] --firstboot-command '
12:17:20 kashyap chmod 0755 /home/stack
12:17:23 kashyap mkdir -m 0755 /home/stack/.ssh'
12:17:44 sean-k-mooney how do you do that declaritvly with out writing a bash script
12:17:54 kashyap sean-k-mooney: I know we're going deep into a non-Nova topic, but 'd-i-b' had the terrible practise of using root overall
12:18:27 kashyap sean-k-mooney: We discussed it when the tool was being written at that time; and pointed to better alternatives ... but they went NIH
12:18:52 sean-k-mooney it use a chroot
12:19:00 sean-k-mooney so root is not system root
12:19:09 sean-k-mooney but ya not a nova topic lets drop it
12:20:30 kashyap sean-k-mooney: It used to use system root, and we discussed the security implications at length. HP at that time wasn't convinced.
12:20:51 kashyap (Yeah, non-Nova, but indirectly very useful topic for Nova Infra :D)
12:27:35 kashyap sean-k-mooney: Not to belabour, but the "diskimage-builder" was so terribly unsafe, at that time the libguestfs folks went and created a "safe wrapper" for it, 'virt-dib': https://manpages.debian.org/testing/libguestfs-tools/virt-dib.1.en.html
12:33:30 sean-k-mooney i see well i still dont think we should replace it with virt-install
12:33:40 sean-k-mooney *virt-builder
12:34:12 sean-k-mooney regardless of the implementaion the design is more approtiate for a git based declaritve workflow IMO
12:34:15 CeeMac lyarwood: quick question, when the domain persistence config is recreated following a successful swap_volume operation, would this generate any new SSIDs against or within the config?
12:34:29 sean-k-mooney which is why i wrote https://github.com/intel-orchestration-software/dib-elements a few year ago using it instead of virt builder
12:40:57 kashyap sean-k-mooney: Yeah, yeah ... I wasn't arguing we shouldn't replace it now (too tedious, and can't justify the effort). The purpose of both tools are different
12:56:53 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: WIP: nova-next: Start testing the 'q35' machine type https://review.opendev.org/708701
12:57:45 kashyap Cc: lyarwood --^ In my above modif, I've nuked the "check" queue altogether, as I see that the 'virt-preview' job is now added to the experimental queue upstream
13:00:03 kashyap (Also see that I've added your F32 support as a Depends-On. Let me know if I messed up anything in the above job config :-))
13:02:17 lyarwood kashyap: yeah you can't do that
13:02:25 lyarwood kashyap: you need to leave a single job in the check queue
13:02:37 lyarwood kashyap: just move the virt-preview job there
13:02:53 kashyap lyarwood: Aah, okay. Noted. Lemme edit :)
13:03:28 kashyap lyarwood: Aside: Sorry, but your "You can't do that" reminded me of a certain president and his conversation with an Australian journalist ;-)
13:09:50 kashyap lyarwood: BTW, also should at least one job be present in the 'gate' queue?
13:10:38 lyarwood kashyap: yes
13:10:45 lyarwood brb
13:11:46 kashyap Thx
13:12:46 kashyap lyarwood: When you're back, that good? —
13:12:47 kashyap gate:
13:12:47 kashyap - devstack-platform-fedora-latest-virt-preview
13:12:47 kashyap jobs:
13:12:47 kashyap check:
13:12:49 kashyap jobs:
13:12:52 kashyap - nova-next
13:14:21 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: WIP: nova-next: Start testing the 'q35' machine type https://review.opendev.org/708701
13:15:14 gmann lyarwood: gibi : zuulv3 grenade is not must for RC. I can try to fix that today but if it goes in W branch then also no issue in backport to V
13:19:43 gibi gmann: thanks
13:20:04 gibi then I will check the gate after the weekly meeting and decide if anything is close, if not we deferr them
13:20:20 gibi gmann: does the same true for the other two zuul migration patch (live migration + evac)
13:20:47 gmann gibi: let me check
13:36:03 gmann lyarwood: gibi nova-grenade-multinode job disappear from run in -https://review.opendev.org/#/c/752557/6
13:36:09 gmann commented on review
13:38:04 gibi gmann: good point
13:41:06 openstack bug 1896463 in OpenStack Compute (nova) "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,Confirmed] https://launchpad.net/bugs/1896463 - Assigned to Balazs Gibizer (balazs-gibizer)
13:41:06 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reproduce bug 1896463 in func env https://review.opendev.org/754100
13:41:22 gibi this is a nasty race ^^
13:43:33 sean-k-mooney that a knonw issue
13:44:29 sean-k-mooney let me see if i can find the downstream bug
13:44:37 lyarwood gmann: urgh sorry, weird how zuul don't complain about that
13:45:25 gmann lyarwood: yeah, that was strange, it think it skipped running it as base job it found from some stable branch and made this job valid only for stable branch. but yes this is confusing
13:45:47 lyarwood loverly
13:46:09 gmann it should be error instead of skip
13:46:12 openstack bugzilla.redhat.com bug 1852110 in openstack-nova "nova host-evacuation returns erroneous pci addresses and an error: Unable to correlate PCI slot" [High,New] - Assigned to smooney
13:46:12 sean-k-mooney gibi https://bugzilla.redhat.com/show_bug.cgi?id=1852110
13:46:17 lyarwood yeah agreed
13:47:38 openstack Launchpad bug 1896463 in OpenStack Compute (nova) "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,Confirmed] - Assigned to Balazs Gibizer (balazs-gibizer)
13:47:38 sean-k-mooney gibi ill add https://bugs.launchpad.net/nova/+bug/1896463 ad the upstream track of the downstream bug
13:47:47 gibi sean-k-mooney: thanks
13:48:04 sean-k-mooney it exist in qeens for what it worth
13:49:22 sean-k-mooney gibi: there are other similar races for retries to other host and a much of issues with shevle and other move operations
13:49:55 sean-k-mooney also all move operation involving PFs dont work as we never update the neutorn port mac
13:50:43 gibi sean-k-mooney: yeah, the problem seems generic for every move that uses migration context and claims
13:51:08 sean-k-mooney yep
13:51:18 gibi now I have a reproducer for evacuate
13:51:22 sean-k-mooney it should not affect live migration for what its worth
13:51:54 sean-k-mooney ya i did not have time to look into this yet since it was only reported downstream in august
13:52:16 sean-k-mooney having a repoducer will certenly help figure out the fix
13:53:08 openstack bugzilla.redhat.com bug 1767797 in openstack-nova "When unshelving an SR-IOV instance, the binding profile isn't reclaimed or rescheduled, and this might cause PCI-PT conflicts" [High,New] - Assigned to nova-maint
13:53:08 sean-k-mooney this is the unshevle case i think https://bugzilla.redhat.com/show_bug.cgi?id=1767797
13:53:28 openstack Launchpad bug 1851545 in OpenStack Compute (nova) "Port update exception on nova unshelve for instance with PCI devices (part 2)" [Medium,Triaged]
13:53:28 sean-k-mooney https://bugs.launchpad.net/nova/+bug/1851545
13:54:16 sean-k-mooney it might be the same root cause. perhapse we coudl copy your repoducer for shelve and see it it causes it
13:54:46 sean-k-mooney gibi: ill try and review it later
13:55:16 gibi could be, I haven't checked the live migration relevance here
13:55:44 sean-k-mooney live migration does not use claims
13:55:57 sean-k-mooney for sriov devies
13:56:13 sean-k-mooney which si why i think it would be fine
13:56:19 gibi ahh, true,
13:57:04 sean-k-mooney pfs still wont work becaue of the mac issue but vfs should be fine
13:57:21 gibi yeah, I keep the PF-mac issue separate
13:57:37 gibi do we have a bug and a reproducer there?
13:57:48 sean-k-mooney while you are in a sriov context you might want to take a look at https://review.opendev.org/#/c/749175/
13:58:15 sean-k-mooney i need to review the latest version but i think its more or less ready to merge after we reopen master and rc1 is done
13:59:25 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Migrate nova-grenade-multinode job to zuulv3 native https://review.opendev.org/742056

Earlier   Later