| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-24 | |||
| 12:12:19 | kashyap | I don't see a single reason to dislike it :D | |
| 12:12:22 | sean-k-mooney | kashyap: i really dont like its workflow and it had rather poor supprot for non rpm distros orginailly | |
| 12:12:39 | sean-k-mooney | i want a declaritive interface which si what the element provide | |
| 12:12:53 | kashyap | sean-k-mooney: Even for non-RPM distros, it even lets you create Ubuntu and Debian images | |
| 12:13:09 | sean-k-mooney | kashyap: right but i hae always had issue trying to use it | |
| 12:13:11 | kashyap | Its main purpose is to allow you creating / modifying images _quickly_ | |
| 12:13:29 | kashyap | What exact issue? I'm surprised such a simple tool fails for you | |
| 12:13:35 | sean-k-mooney | for me its never been quick and i dont find its docs that easy to folow | |
| 12:14:00 | sean-k-mooney | the first road block whas always been user managment | |
| 12:14:16 | sean-k-mooney | injection of ssh keys ectra | |
| 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 | virt-builder [...] --firstboot-command ' | |
| 12:17:18 | kashyap | # Create the user account. | |
| 12:17:18 | kashyap | useradd -m -p "" -G wheel stack | |
| 12:17:18 | kashyap | chage -d 0 stack | |
| 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 | check: | |
| 13:12:47 | kashyap | jobs: | |
| 13:12:47 | kashyap | - devstack-platform-fedora-latest-virt-preview | |
| 13:12:47 | kashyap | gate: | |
| 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 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1896463 in func env https://review.opendev.org/754100 | |
| 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: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 | sean-k-mooney | gibi https://bugzilla.redhat.com/show_bug.cgi?id=1852110 | |
| 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:17 | lyarwood | yeah agreed | |
| 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: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: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 | sean-k-mooney | this is the unshevle case i think https://bugzilla.redhat.com/show_bug.cgi?id=1767797 | |
| 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:28 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1851545 | |
| 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: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 | |