VNC keymaps (issue 100)
Jorge Manuel B. S. Vicetto
I'm creating my first ganeti cluster and while working through it,
I've come across issue 100[1].
One of the complaints about the proposed patch was that it used a
static list of keymaps. I've noticed that in Gentoo we install the
keymaps into /usr/share/qemu/keymaps. The files have the language
names, but it also includes 2 files named common and modifiers. Should
ganeti search for files here or would it make more sense to open a
feature request for qemu / kvm to provide a list of supported
languages? Another issue is that the list of languages might (is?)
tied to the qemu / kvm version on each node. So should the query be
made to the specific node a vm is running on?
[1] -http://code.google.com/p/ganeti/issues/detail?id=100
I realize that issue 100 was closed because the user didn't accept the
CLA, but I don't think that prevents a discussion about the points
I've raised.
Regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer
Jorge Manuel B. S. Vicetto
I forgot to mention that another desired feature is to add the support
for the RAPI interface to select the VNC keymap and provide the list
of available keymaps, so that clients such as ganeti_webmgr can
provide that option to users as well.
Jorge Manuel B. S. Vicetto
Following my previous email about the keymaps option for ganeti, I've
updated the patch on issue 100[1] to apply to ganeti-2.3.1 and to
include all the keymaps available on qemu-kvm-0.13.0. The patch is
attached.
It's still using a static list of keymaps as my questions in the
previous email got no answers.
After applying this patch, gnt-instance doesn't present the option for
the kvm hypervisor. Do I need to update the lib/client/gnt-instance.py
file or do anything else?
[1] -http://code.google.com/p/ganeti/issues/detail?id=100
Iustin Pop
> Hi.
Hi,
> Following my previous email about the keymaps option for ganeti, I've
> updated the patch on issue 100[1] to apply to ganeti-2.3.1 and to
> include all the keymaps available on qemu-kvm-0.13.0. The patch is
> attached.
Since this patch started from one that we couldn't accept due to CLA, I
believe we couldn't accept this either, sorry.
> It's still using a static list of keymaps as my questions in the
> previous email got no answers.
Sorry, didn't have time to respond. I believe the static list of keys is
bad because hardcodes into Ganeti the list of available keymaps, and
that would require us to update Ganeti anytime this changes on QEMU
side.
The proposal about loading the list of keymaps from disk is OK; we could
have a variable that defines the directory (e.g. HT_KEYMAPS_PATH) and
then we examine that. Regarding the difference between nodes, we
_should_ have consistent nodes, more or less.
As to filing a patch against QEMU to expose the list of keymaps, that
would be excellent!
> After applying this patch, gnt-instance doesn't present the option for
> the kvm hypervisor. Do I need to update the lib/client/gnt-instance.py
> file or do anything else?
What do you mean exacly "doesn't present the option"? Have you
customised it with gnt-instance modify, rebooted the instance and still
doesn't take effect?
regards,
iustin
Jorge Manuel B. S. Vicetto
> On Fri, Apr 29, 2011 at 10:13:38PM +0000, Jorge Manuel B. S. Vicetto wrote:
>> Hi.
>
> Hi,
>
>> Following my previous email about the keymaps option for ganeti, I've
>> updated the patch on issue 100[1] to apply to ganeti-2.3.1 and to
>> include all the keymaps available on qemu-kvm-0.13.0. The patch is
>> attached.
>
> Since this patch started from one that we couldn't accept due to CLA, I
> believe we couldn't accept this either, sorry.
Bummer. I can still use it locally, but it would be great if it would
be added to ganeti.
As my patch could easily have been based on the "floppy" patch, I
could have used different names than the ones in the issue 100 patch
but the variable types and check validation would be similar, how
"different" would the patch need to be for you to be able to accept
it?
>> It's still using a static list of keymaps as my questions in the
>> previous email got no answers.
>
> Sorry, didn't have time to respond. I believe the static list of keys is
> bad because hardcodes into Ganeti the list of available keymaps, and
> that would require us to update Ganeti anytime this changes on QEMU
> side.
No complaint from me, I was just explaining why I was using a static
list after having addressed that point in a previous email.
I understand and agree with the weakness of using a static list.
> The proposal about loading the list of keymaps from disk is OK; we could
> have a variable that defines the directory (e.g. HT_KEYMAPS_PATH) and
> then we examine that. Regarding the difference between nodes, we
> _should_ have consistent nodes, more or less.
Ok, I'll see if I can present a patch for that.
> As to filing a patch against QEMU to expose the list of keymaps, that
> would be excellent!
I'll do that then.
>> After applying this patch, gnt-instance doesn't present the option for
>> the kvm hypervisor. Do I need to update the lib/client/gnt-instance.py
>> file or do anything else?
>
> What do you mean exacly "doesn't present the option"? Have you
> customised it with gnt-instance modify, rebooted the instance and still
> doesn't take effect?
After updating ganeti in the node, when I try to modify the instance
and add the parameter, ganeti complains that the parameter is invalid.
$ sudo gnt-instance modify -H kbd_layout=pt <instance>
Parameter Error: Unknown key 'kbd_layout'
$ grep -R kbd_layout /usr/lib/python2.6/site-packages/ganeti/*
/usr/lib/python2.6/site-packages/ganeti/constants.py:HV_KBD_LAYOUT =
"kbd_layout"
Binary file /usr/lib/python2.6/site-packages/ganeti/constants.pyc matches
Binary file /usr/lib/python2.6/site-packages/ganeti/constants.pyo matches
Binary file /usr/lib/python2.6/site-packages/ganeti/hypervisor/hv_kvm.pyc
matches
/usr/lib/python2.6/site-packages/ganeti/hypervisor/hv_kvm.py:
kbd_layout = hvp[constants.HV_KBD_LAYOUT]
/usr/lib/python2.6/site-packages/ganeti/hypervisor/hv_kvm.py: if kbd_layout:
/usr/lib/python2.6/site-packages/ganeti/hypervisor/hv_kvm.py:
kvm_cmd.extend(['-k', kbd_layout])
Binary file /usr/lib/python2.6/site-packages/ganeti/hypervisor/hv_kvm.pyo
matches
> regards,
> iustin
Regards,
Jorge.
Iustin Pop
> On Sat, Apr 30, 2011 at 7:11 AM, Iustin Pop <ius...@google.com> wrote:
> > On Fri, Apr 29, 2011 at 10:13:38PM +0000, Jorge Manuel B. S. Vicetto wrote:
> >> Hi.
> >
> > Hi,
> >
> >> Following my previous email about the keymaps option for ganeti, I've
> >> updated the patch on issue 100[1] to apply to ganeti-2.3.1 and to
> >> include all the keymaps available on qemu-kvm-0.13.0. The patch is
> >> attached.
> >
> > Since this patch started from one that we couldn't accept due to CLA, I
> > believe we couldn't accept this either, sorry.
>
> Bummer. I can still use it locally, but it would be great if it would
> be added to ganeti.
> As my patch could easily have been based on the "floppy" patch, I
> could have used different names than the ones in the issue 100 patch
> but the variable types and check validation would be similar, how
> "different" would the patch need to be for you to be able to accept
> it?
Well, I am not a lawyer, so I have no idea how this goes. I would have
to check, but I rather more prefer the non-static approach anyway, so…
>
> >> It's still using a static list of keymaps as my questions in the
> >> previous email got no answers.
> >
> > Sorry, didn't have time to respond. I believe the static list of keys is
> > bad because hardcodes into Ganeti the list of available keymaps, and
> > that would require us to update Ganeti anytime this changes on QEMU
> > side.
>
> No complaint from me, I was just explaining why I was using a static
> list after having addressed that point in a previous email.
> I understand and agree with the weakness of using a static list.
Ack.
Ah, I see. What version of Ganeti do you use? And what does the
maste-daemon.log file (/var/log/ganeti) say about exactly where this
error was raised?
thanks,
iustin
Jorge Manuel B. S. Vicetto
> On Sat, Apr 30, 2011 at 09:59:47PM +0000, Jorge Manuel B. S. Vicetto wrote:
>> On Sat, Apr 30, 2011 at 7:11 AM, Iustin Pop <ius...@google.com> wrote:
>> > On Fri, Apr 29, 2011 at 10:13:38PM +0000, Jorge Manuel B. S. Vicetto wrote:
>> >> Hi.
>> >
>> > Hi,
>> be added to ganeti.
>> As my patch could easily have been based on the "floppy" patch, I
>> could have used different names than the ones in the issue 100 patch
>> but the variable types and check validation would be similar, how
>> "different" would the patch need to be for you to be able to accept
>> it?
>
> Well, I am not a lawyer, so I have no idea how this goes. I would have
> to check, but I rather more prefer the non-static approach anyway, so…
I see. I'll try to present a non-static patch then.
I'm running ganeti-2.3.1 on gentoo.
Here is the relevant section from the log:
2011-05-01 11:04:34,251: ganeti-masterd pid=8780/MainThread INFO
Accepted connection from pid=1897, uid=0, gid=0
2011-05-01 11:04:34,252: ganeti-masterd pid=8780/ClientReq9 INFO
Received new job
2011-05-01 11:04:34,259: ganeti-masterd pid=8780/ClientReq1 INFO
Received job poll request for 255
2011-05-01 11:04:34,262: ganeti-masterd pid=8780/JobQueue5/Job255 INFO
Op 1/1: opcode INSTANCE_SET_PARAMS(hseahservv01) waiting for locks
2011-05-01 11:04:34,263: ganeti-masterd pid=8780/ClientReq15 INFO
Received job poll request for 255
2011-05-01 11:04:34,268: ganeti-masterd pid=8780/ClientReq16 INFO
Received job poll request for 255
2011-05-01 11:04:34,270: ganeti-masterd pid=8780/JobQueue5/Job255
ERROR Op 1/1: Caught exception in INSTANCE_SET_PARAMS(hseahservv01)
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/ganeti/jqueue.py", line
920, in _ExecOpCodeUnlocked
timeout=timeout, priority=op.priority)
File "/usr/lib64/python2.6/site-packages/ganeti/mcpu.py", line 388,
in ExecOpCode
priority)
File "/usr/lib64/python2.6/site-packages/ganeti/mcpu.py", line 332,
in _LockAndExecLU
result = self._LockAndExecLU(lu, level + 1, calc_timeout, priority)
File "/usr/lib64/python2.6/site-packages/ganeti/mcpu.py", line 332,
in _LockAndExecLU
result = self._LockAndExecLU(lu, level + 1, calc_timeout, priority)
File "/usr/lib64/python2.6/site-packages/ganeti/mcpu.py", line 292,
in _LockAndExecLU
result = self._ExecLU(lu)
File "/usr/lib64/python2.6/site-packages/ganeti/mcpu.py", line 252, in _ExecLU
lu.CheckPrereq()
File "/usr/lib64/python2.6/site-packages/ganeti/cmdlib.py", line
9192, in CheckPrereq
utils.ForceDictType(i_hvdict, constants.HVS_PARAMETER_TYPES)
File "/usr/lib64/python2.6/site-packages/ganeti/utils.py", line 831,
in ForceDictType
raise errors.TypeEnforcementError(msg)
TypeEnforcementError: Unknown key 'kbd_layout'
2011-05-01 11:04:34,271: ganeti-masterd pid=8780/ClientReq2 INFO
Received job poll request for 255
2011-05-01 11:04:34,274: ganeti-masterd pid=8780/JobQueue5/Job255 INFO
Finished job 255, status = error
2011-05-01 11:04:34,806: ganeti-masterd pid=8780/ClientReq14 INFO
Received job query request for 255
> thanks,
> iustin
Regards,
Jorge.
Iustin Pop
This says that the kbd_layout key is not presents in the
HVS_PARAMETER_TYPES dictionary, but your patch adds it correctly.
Could it be that the code on the server doesn't have the patch applied
correctly, or that you didn't restart the master daemon after applying
it?
I would add some logging right above this which dumps the
HVS_PARAMETER_TYPES dict in order to double-check what's going on…
regards,
iustin
Jorge Manuel B. S. Vicetto
I hadn't restarted the master daemon. It now supports setting the option.
Thank you.