10:40 p.m.
On 11/17/2014 12:58 PM, Aline Manera wrote:
On 11/12/2014 09:00 PM, Christy Perez wrote:
> This is another rework of how this flow should work, after more
> thought and
> discussion with Aline.
>
> This new flow removes the 'auto-topology' element from the API and
> makes it so that
> users can enter varying information without being dinged for not doing
> exactly the
> right thing (e.g. vcpus != sockets * cores * threads).
>
> It also works in a way that doesn't require the UI to have access to
> the kimchi Model objects (as I misremembered for the previous patches).
>
> 1. UI calls GET host/cpuinfo
>
> curl -k -u user -H 'Content-Type: application/json' \
> -H 'Accept: application/json'
> https://localhost:8001/host/cpuinfo
> {
> "cores":2,
> "threading_enabled":true,
> "sockets":1,
> "threads_per_core":2
> }
>
> 2. UI displays appropriate title and checkboxes
> - If host arch is Power:
> - Display a menu labled SMT, with up to four check-boxes.
> The check-boxes will be labeled SMT1, SMT2, SMT4, and SMT8.
> The max SMT value displayed will be dependant upon
> threads_per_core from above. The default checkbox should be
> the
> greatest SMT value (e.g. SMT8).
> - Display the same box for CPUs as before. This value may change
> when the backend template creation is done, so if there's
> any way
> to pop up "Here are the values of your new template," kind
> of message,
> that would be nice. Otherwise, we'll just make it clear in
> the doc
> that the vCPUs value entered is not guaranteed.
I don't like this approach. As an user I like to inform the CPU number
and be sure it will be in use.
I didn't really like it either, so I've redone things in the backend and
this won't happen. Can we pick up this discussion on my next (v5)
patchset? I'm about to test it, and then I'll send it out.
Maybe we could change the way we display it to user.
I checked on virt-manager and it allows user informs the 3 values:
sockets, threads and cores.
The values of threads are the SMTX values. So we can display them as a
combo box according to /host/cpu_info response.
The other 2 values could be collected as an input box. And the CPU will
be themultiplication of those values.
So on UI we could have a new tab on Edit Template named "Processor".
In the first view we will have:
CPU number: [______________]
[ ] Manually inform CPU topology
("Manually configure CPU topology."
sounds better)
I like this option a lot. I thought that you were against it from the
beginning, though, and that you only wanted users to be able to enter
these values if there was some kind of "advanced" part of kimchi (to be
added later).
If the UI passes in those values, the backend can already handle it
(since the topology bits have been in kimchi backend for a while now).
But -- again -- let's pick this up on my next patchset. I have already
been guilty of fragmenting these discussions over the UI patchsets and
my different ones. :)
I'll assume that the user has the ability to do either automatic, or
manual when I write up the v5 summary.
Once the "Manually inform CPU topology" is selected, the expand to show
3 new fields and make the "CPU number" field disabled.
Sockets: [______________]
Cores : [______________]
Threads: [______________] => this is a combo box with the SMTX
options (only the numbers)
On values changes in those 3 fields the "CPU number" is updated to
display sockets * cores * threads
And with this approach we don't need to differ x86 from ppc.
> - Else:
> - Display a menu labeled Hyper-Threading, with only a
> checkbox labeled
> HT.
> Note: The same comments for vCPUS as above apply here. The
> number
> maybe need to change based on the CPU capabilities.
>
> 3. UI calls POST template with threads value set to '0' (x86) or SMTX
> (Power)
> Note that vcpus is still optional, so no change in how that's
> handled needs
> to be done.
>
> $ curl -k -u user -X POST -H 'Content-Type: application/json' -H
> 'Accept: application/json' https://localhost:8001/templates
> -d'{"name": "test_auto_topo", "cdrom":
> "/home/iso-pool/Fedora-Live-Desktop-x86_64-20-1.iso",
"cpu_info":
> {"topology": {"threads":0}}}'
>
> {
> "cpus":1,
> "cpu_info":{
> "topology":{
> "cores":1,
> "threads":1,
> "sockets":1
> }
> },
> "graphics":{
> "type":"vnc",
> "listen":"127.0.0.1"
> },
> "cdrom":"/home/iso-pool/Fedora-Live-Desktop-x86_64-20-1.iso",
> "networks":[
> "default"
> ],
> "icon":"images/icon-fedora.png",
> "os_distro":"fedora",
> "name":"test_auto_topo",
> "disks":[
> {
> "index":0,
> "size":10
> }
> ],
> "invalid":{},
> "os_version":"20",
> "storagepool":"/storagepools/default",
> "memory":1024,
> "folder":[]
> }
>
> Regards,
>
> - Christy
>
> Christy Perez (1):
> Parts to allow Kimchi to configure the cpu topology.
>
> docs/API.md | 28 +++++++
> src/kimchi/API.json | 11 +--
> src/kimchi/control/cpuinfo.py | 37 +++++++++
> src/kimchi/control/host.py | 2 +
> src/kimchi/i18n.py | 3 +-
> src/kimchi/model/cpuinfo.py | 172
> ++++++++++++++++++++++++++++++++++++++++++
> src/kimchi/model/host.py | 1 +
> src/kimchi/model/templates.py | 25 ++++--
> 8 files changed, 263 insertions(+), 16 deletions(-)
> create mode 100644 src/kimchi/control/cpuinfo.py
> create mode 100644 src/kimchi/model/cpuinfo.py
>