Qubes Admin API #853

Open
marmarek opened this Issue Mar 8, 2015 · 18 comments

Projects

None yet

4 participants

@marmarek
Member
marmarek commented Mar 8, 2015 edited

Reported by joanna on 10 May 2014 12:56 UTC
https://groups.google.com/d/msg/qubes-devel/f2gDpXE3NJ8/_kH7LUrzJ80J

Migrated-From: https://wiki.qubes-os.org/ticket/853


Note to any contributors who wish to work on this issue: Please either ask for details or propose a design before starting serious work on this.

@marmarek marmarek added this to the Release 3 milestone Mar 8, 2015
@marmarek marmarek modified the milestone: Release 3.1, Release 3.0 May 13, 2015
@marmarek marmarek modified the milestone: Release 4.1, Release 3.1 Feb 8, 2016
@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 9, 2016
@andrewdavidwong andrewdavidwong Update #853 status e396c64
@woju
Member
woju commented Nov 18, 2016

Just pushed a draft of the API, to the qubes-doc, since the table is messy and won't be readable in the issue.

https://www.qubes-os.org/doc/mgmt1/

Didn't link anywhere yet.

@andrewdavidwong could you look on the page? It breaks the layout horribly and I don't know how to make this neither pretty nor readable. I took a shortcut and embedded a <style> directly in the page, which is bad, too.

@andrewdavidwong
Member

@woju: No problem; I'll work on this soon.

@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubes-doc that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Convert table to Markdow and remove custom styling bb99c1a
@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubes-doc that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Remove extra table cells; substitute HTML entity for vbar 06b2edc
@andrewdavidwong
Member

@woju: How does it look now? (Note: You might need to clear your cache to get the new CSS.)

@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubes-doc that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Clean up table source
* Use backticks to wrap literal text
* Replace HTML entities with ASCII characters
* Make column spacing uniform

QubesOS/qubes-issues#853
889a830
@woju
Member
woju commented Nov 19, 2016

Thanks. It is prettier, though it's less readable, since it gets scrolled independent of page, and wraps the cells. I disabled it on purpose, because if there is <name> class=<class> state=<state>\n, I didn't want it to get on multiple lines.

@andrewdavidwong
Member

Thanks. It is prettier, though it's less readable, since it gets scrolled independent of page,

The only way to avoid that is to use a different layout for the page. It sounds like maybe you don't want it to have the doc layout with the right-hand side bar. If the table doesn't get clipped, it'll simply overlap that side bar and be even less readable.

and wraps the cells. I disabled it on purpose, because if there is class= state=\n, I didn't want it to get on multiple lines.

Ok.

@marmarek
Member

Scrolling horizontally IMO isn't a problem - vertically is.

@andrewdavidwong
Member

If the table doesn't get clipped vertically, it'll be larger than the height of most viewports. My impression is that this is bad practice in web design, but I don't have any source to back that up.

@andrewdavidwong
Member

What if we create a full layout version of the table that takes up an entire page and provide a link from the existing page underneath the clipped table?

Alternatively, we could convert the entire page into the full layout and lose the side bar.

@woju
Member
woju commented Nov 19, 2016

I don't mind the side bar disappearing at all. And, as Marek said, table shouldn't be vertically scrollable independent of the page, because it makes it very annoying on touchscreen.

You may be right in the sense that nowadays it is fashionable to design custom scrolling, those designers do it and people get used to that, but IMHO this is not usable.

It may be valuable to devise some CSS class for the tables in documentation, since I will have at least two more such tables, for VM "events" and "features" (new functionality in R4.0 core).

But we are getting sidetracked.

@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubesos.github.io that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Tables: Do not limit vertical height or wrap whitespace f336223
@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubesos.github.io that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Create layout for full-size documentation pages 862f9e0
@andrewdavidwong andrewdavidwong added a commit to QubesOS/qubes-doc that referenced this issue Nov 19, 2016
@andrewdavidwong andrewdavidwong Use new doc-full layout to prevent table scrolling c8b57d8
@andrewdavidwong
Member

@woju @marmarek: Let me know what you think now.

@woju
Member
woju commented Nov 19, 2016

Great! Thank you.

@kalkin
Member
kalkin commented Nov 21, 2016

@woju What should mgmt1.vm.volume.List list?

@woju
Member
woju commented Nov 23, 2016

@kalkin some identifier about the volume and possibly very basic info, but I'm not sure what exactly.

The idea is that there are two set of calls, mgmt1.vm.volume.* and mgmt1.pool.volume.*, to allow for expressing the policy decisions "allow management of pool" and "allow management of storage for VM". They overlap in scope, on purpose. Currently I don't know who will use which one and in what context.

@woju woju added a commit to QubesOS/qubes-doc that referenced this issue Nov 24, 2016
@woju woju services/mgmt1: various updates
- remove `1` from RPC names
- change `mgmt.vm.Create` wrt class
- misc notes and TODOs

QubesOS/qubes-issues#853
d82e47c
@marmarek
Member
marmarek commented Feb 13, 2017 edited

Issue(s) with current API draft:

  • missing handling of global properties: I propose mgmt.property. prefix with exactly the same set of actions as for mgmt.vm.property.. Or maybe mgmt.global.property. ?
  • Very limited error reporting - for example the reason why VM startup failed (no such VM, not enough memory, missing files, etc)
  • mgmt.vm.property.List and mgmt.vm.property.Help are bound to VM instance at API level, while in practice those are bound to VM class. Generally I'm ok with that, but I face a practical issue: don't know how to properly handle docstrings for client-side wrappers. Our API have vm.property_list, so this part is not a problem (IMO dir(vm) not working is not a problem), but no idea how to handle help(VMClass.property). Maybe shouldn't? And handle only docstring on the object(s) returned by vm.property_list?
  • missing calls for cloning - either at VM level (mgmt.vm.Clone), or individual elements (mgmt.vm.property.Clone, mgmt.vm.volume.Clone etc). I'm in favor of the first option (full VM clone with just new name+qid).
@marmarek
Member

And issues with current qubesd implementation:

  • No way to distinguish empty return data from failed call (at local socket level). Maybe qubesd should always respond with OK/FAIL on the first line and only then with actual data - this could be translated by qubesd-query to exit code.
@woju
Member
woju commented Feb 22, 2017
  • A way to query for vm -> label colour for GUI domain.
  • Some way of editing labels themselves? (see #2523 where I got)
@marmarek
Member
marmarek commented Feb 22, 2017 edited

A way to query for vm -> label colour for GUI domain.

mgmt.vm.property.Get+label? But it will give only label name, not other properties (color, icon). Maybe we need mgmt.vm.label.*? But the target of this call can't be a label, must be some VM (probably dom0).

Also:

  • A way to query state of a single VM (and maybe VM existence check at the same time). Proposal: allow calling mgmt.vm.List to a specific VM, not only to dom0.
@marmarek
Member
marmarek commented Feb 23, 2017 edited
  • Serialization of VM type (like 'netvm' property). Should it be just string? Then stubs deserializing it will have no idea it's more than string (vm.netvm.ip will not work). Maybe we need explicit type declaration in result of *.Get methods - instead of default=yes|no value, it would be default=yes|no type=... value?

Note that *.Set calls don't have this problem, because qubesd know what type should be there, and it's responsibility of appropriate handler to convert string to appropriate type. Actually it would be wrong to pass any type information here - it would make parsing of untrusted input more complex.

@marmarek marmarek added a commit to marmarek/qubes-core-mgmt-client that referenced this issue Feb 23, 2017
@marmarek marmarek Initial commit
First minimal version, with just listing VMs and handling properties.

QubesOS/qubes-issues#853
a20a178
@marmarek marmarek added a commit to marmarek/qubes-core-mgmt-client that referenced this issue Feb 23, 2017
@marmarek marmarek Rename '_do_qubesd_call' to 'qubesd_call'
This method don't need to be private. Also the 'do_' prefix is
superfluous - methods typically do something.

QubesOS/qubes-issues#853
1127a1a
@marmarek marmarek added a commit to marmarek/qubes-core-mgmt-client that referenced this issue Feb 23, 2017
@marmarek marmarek Fix py3k compatibility 8770857
@marmarek marmarek added a commit to marmarek/qubes-core-mgmt-client that referenced this issue Feb 24, 2017
@marmarek marmarek Avoid cyclic imports 903290c
@marmarek marmarek added a commit to marmarek/qubes-core-mgmt-client that referenced this issue Feb 24, 2017
@marmarek marmarek Cache vm.name property
It doesn't make sense to send mgmt call to _named_ VM just to ask for
its name. Use value that QubesVM object already have.
This also means we can safely access vm.name, no need to touch any
private attribute.

QubesOS/qubes-issues#853
f147e27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment