Remove nova default keymap option for qemu-kvm (deprecated)

is there any guideline or links you mentioned above for the deprecation?
And the patch you showed seems only remove the default value, so we need totally deprecate the whole option and don't use it in the future?

Hi all,

I have confirmed with the qemu community whether -k keymap option is deprecated or not. As per pjp developer, it's not deprecated.

Please find below discussions on the #qemu irc channel.

Got the reference of #qemu channel from http://www.qemu.org/contribute/
IRC: irc.oftc.net, channel #qemu

IRC Logs:

<pre>
<Dinesh_Bhor> Hi all, I have a doubt. Hope someone will answer. Is qemu-kvm default keymap option -k en-us, or any keymap option is deprecated ? If yes where can I find the documentation related to it.
<Dinesh_Bhor> or is there any future plan to deprecate it?
<Dinesh_Bhor> pm215: Hi, can you help me with this? ^^
<pjp> Dinesh_Bhor: I doubt it's deprecated, why do you think it is?
<Dinesh_Bhor> pjp: someone has reported a bug in openstack-nova that this is deprecated: https://bugs.launchpad.net/nova/+bug/1682020
<Dinesh_Bhor> pjp: so I just want to confirm it
<pjp> Dinesh_Bhor: Built qemu from latest git, qemu-system-x86_64 does show -k option,
<Dinesh_Bhor> pjp: it's not showing any deprecation message when you run this command. right?
<pjp> Dinesh_Bhor: Nope
<Dinesh_Bhor> pjp: ok, thank you for your help
<Dinesh_Bhor> pjp: one more question. Where can I find this channel's logs?
<pjp> Dinesh_Bhor: Not sure
<Dinesh_Bhor> pjp: ok, np, thanks
</pre>

Secondly, I have checked ChangeLogs for the last 3 releases and I couldn't see the option -k keymap is deprecated.

http://wiki.qemu.org/index.php?title=Special:AllPages&from=ChangeLog/&to=ChangeLog/zzzzz&namespace=0

<pre>
http://wiki.qemu.org/ChangeLog/2.9
http://wiki.qemu.org/ChangeLog/2.8
http://wiki.qemu.org/ChangeLog/2.7
</pre>

In the Dinesh #3 comment above, 'pjp' is 'Prasad J Pandit'.
He has committed many patches to the Qemu project so we assume he has basic knowledge to tell if any parameter is deprecated or not.

http://git.qemu.org/?p=qemu.git;a=search;h=HEAD;s=Prasad+J+Pandit;st=author

It is more subtle than suggested by that quote IRC conversation.

The "-k" option isn't marked as deprecated in the QEMU docs because it applies to several different areas of the QEMU code, and it can sometimes be valid to use it (primarily for interacting with QEMU via stdin on the text console. If you are using the VNC server though, it is *strongly* recommended to *NEVER* add the "-k" option, because it will force QEMU to do keymap conversions which are known to be lossy. The result is that users (particularly those with non-US layout keyboards) will be unable to enter certain key combinations. Leave out "-k", and allow VNC clients to pass through raw scan codes directly to the guest without any lossy munging by QEMU.

NB, I am a long term maintainer of the QEMU VNC code & the GTK-VNC client.

Fix proposed to branch: master
Review: https://review.openstack.org/483994

Hi Daniel,

I have checked impact of w/ and w/o -k option with different combinations of default locale configured in client os and guest os.

In case of RHEL image with default locale 'ja_JP' and client default locale set as 'ja_JP', I have noticed that with -k option, only one character was giving problem with Japanese keyboard whereas without -k option I couldn't enter 4 characters and also many other characters were displayed incorrectly.

Presently, -k option passed to qemu can be configured using 'vnc.keymap' parameter on nova compute node, but it's remain the same for all vms running on that particular compute host. If we allow to pass keymap parameter to boot api [1](specs are up for review), then a user can specify which keymap to be used during booting instance based on the keymap that he/she will configure in the client os (machine from where user will access the vm using vnc console). This way, I think user should be able to get better results.

Please let me know what do you think abouut it.

Thank you.

[1] : https://review.openstack.org/#/c/448830

Related fix proposed to branch: master
Review: https://review.openstack.org/496605

Reviewed: https://review.openstack.org/496605
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d983234288728427235ef2c1f355ec135119b865
Submitter: Jenkins
Branch: master

commit d983234288728427235ef2c1f355ec135119b865
Author: Stephen Finucane <email address hidden>
Date: Wed Aug 23 11:15:17 2017 +0100

    conf: Allow users to unset 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this.

    In the long term, we would like to deprecate these options. However, we
    must do this in three parts. This part allows users to unset the options
    and warns users who have them set about the side effects. This change is
    intended to be backported. A future change will fully deprecate the
    options. Finally, after the deprecation cycle has passed, we can remove
    these options in their entirety.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I6b1d719db0537b0f53768dbb00a5b4d01c85ba3a
    Related-Bug: #1682020

Related fix proposed to branch: stable/pike
Review: https://review.openstack.org/498509

Reviewed: https://review.openstack.org/498509
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ccfb46420d6ee186d6ec777ce6167bd138f2a285
Submitter: Jenkins
Branch: stable/pike

commit ccfb46420d6ee186d6ec777ce6167bd138f2a285
Author: Stephen Finucane <email address hidden>
Date: Wed Aug 23 11:15:17 2017 +0100

    conf: Allow users to unset 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this.

    In the long term, we would like to deprecate these options. However, we
    must do this in three parts. This part allows users to unset the options
    and warns users who have them set about the side effects. This change is
    intended to be backported. A future change will fully deprecate the
    options. Finally, after the deprecation cycle has passed, we can remove
    these options in their entirety.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I6b1d719db0537b0f53768dbb00a5b4d01c85ba3a
    Related-Bug: #1682020
    (cherry picked from commit d983234288728427235ef2c1f355ec135119b865)

Related fix proposed to branch: master
Review: https://review.openstack.org/547985

Reviewed: https://review.openstack.org/547985
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635
Submitter: Zuul
Branch: master

commit ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635
Author: Matt Riedemann <email address hidden>
Date: Mon Feb 26 05:53:57 2018 -0500

    Update noVNC deployment docs to mention non-US keymap fix in 1.0.0

    noVNC 1.0.0 has the fix for non-US key mappings so this adds a simple
    note when installing the novnc package that at least 1.0.0 should be
    used for non-US key map support.

    Change-Id: Ia1a84c986025f8a46c1062440faa0deb1d2d73a5
    Related-Bug: #1682020

Related fix proposed to branch: stable/queens
Review: https://review.openstack.org/548057

Reviewed: https://review.openstack.org/548057
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=733b61527da7e1961548966360a9241b2a304014
Submitter: Zuul
Branch: stable/queens

commit 733b61527da7e1961548966360a9241b2a304014
Author: Matt Riedemann <email address hidden>
Date: Mon Feb 26 05:53:57 2018 -0500

    Update noVNC deployment docs to mention non-US keymap fix in 1.0.0

    noVNC 1.0.0 has the fix for non-US key mappings so this adds a simple
    note when installing the novnc package that at least 1.0.0 should be
    used for non-US key map support.

    Change-Id: Ia1a84c986025f8a46c1062440faa0deb1d2d73a5
    Related-Bug: #1682020
    (cherry picked from commit ed7af4c8f4d72ed0a1c15daf1c700b07fbeed635)

Related fix proposed to branch: master
Review: https://review.openstack.org/550173

Reviewed: https://review.openstack.org/483994
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=cab8139498c7ea6b05cfdc8b4997276051b943fc
Submitter: Zuul
Branch: master

commit cab8139498c7ea6b05cfdc8b4997276051b943fc
Author: Stephen Finucane <email address hidden>
Date: Fri Jul 14 17:00:27 2017 +0100

    conf: Deprecate 'keymap' options

    Defining the 'keymap' option in libvirt results in the '-k' option being
    passed through to QEMU [1][2]. This QEMU option has some uses, primarily
    for users interacting with QEMU via stdin on the text console. However,
    for users interacting with QEMU via VNC or Spice, like nova users do, it
    is strongly recommended to never add the "-k" option. Doing so will
    force QEMU to do keymap conversions which are known to be lossy. This
    disproportionately affects users with non-US keyboard layouts, who would
    be better served by relying on the guest OS to manage this. Users should
    instead rely on their clients and guests to correctly configure this.

    This is the second part of the three part deprecation cycle for these
    options. At this point, they are retained but deprecated them and their
    defaults modified to be unset. This allows us to warn users with libvirt
    hypervisors that have configured the options about the pitfalls of the
    option and give them time to prepare migration strategies, if necessary.
    A replacement option is added to the VMWare group to allow us to retain
    this functionality for that hypervisor. Combined with the above, this
    will allow us to remove the options in a future release.

    [1] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L6985-L6986
    [2] https://github.com/libvirt/libvirt/blob/v1.2.9-maint/src/qemu/qemu_command.c#L7215-L7216

    Change-Id: I9a50a111ff4911f4364a1b24d646095c72af3d2c
    Closes-Bug: #1682020

This issue was fixed in the openstack/nova 18.0.0.0b1 development milestone.

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.openstack.org/550173
Reason: Realistically, this shouldn't merge until Ubuntu 20.04 is out and Fedora 28 symlinks the path [1] making this unnecessary. Let's abandon this for now.

[1] https://src.fedoraproject.org/rpms/novnc/blob/master/f/novnc.spec#_36

Reading the above, I wanted to take advantage of removing the -t option, and using non-US keyboards. However it turns out that in our Ussuri installation on Bionic, we still get novnc 1:0.4+dfsg+1+20131010+gitf68af8af3d-7.

Would it not be a good idea to have version >= 1.0.0 in the Ubuntu Cloud Archive?

s/-t/-k/