<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 27, 2017 at 8:59 AM, Tomas Jelinek <span dir="ltr">&lt;<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_-971199036686354921h5">On Mon, Mar 27, 2017 at 1:32 PM, Juan Hernández <span dir="ltr">&lt;<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">On 03/27/2017 01:03 PM, Tomas Jelinek wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Mar 27, 2017 at 11:21 AM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a><br>
</span><div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">&gt; &lt;mailto:<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     Top posting, sorry.<br>
&gt;<br>
&gt;     There are a few things I&#39;d like to clarify, regarding this subject:<br>
&gt;<br>
&gt;     1. Data aggregation, as requested now by Tomas, and by other people in<br>
&gt;     the past.<br>
&gt;<br>
&gt;     We used to have that &#39;detail&#39; parameter, to aggregate certain very<br>
&gt;     specific types of data, in particular to aggregate VM disks and NICs. We<br>
&gt;     removed that in version 4 of the API because the implementation was<br>
&gt;     extremely inefficient, from the engine point of view. An innocent<br>
&gt;     request like this:<br>
&gt;<br>
&gt;       GET /ovirt-engine/api/vms?detail=+<wbr>disks,+nics<br>
&gt;<br>
&gt;     Would generate, with the implementation we used to have, 1 query for the<br>
&gt;     VMs and then as many queries for disks and NICs as VMs in the system. In<br>
&gt;     our scale test environments, for example, with approx 4000 VMs and 10000<br>
&gt;     disks, that would take more than 20 hours to execute.<br>
&gt;<br>
&gt;     In addition, we didn&#39;t have in the past any mechanism to make this<br>
&gt;     available in a generic one, because there was no knowledge in the API of<br>
&gt;     what are &#39;details&#39;.<br>
&gt;<br>
&gt;     In version 4 of the API we introduced a formal (kind of) specification<br>
&gt;     of the API (a.k.a. the model), and int includes knowledge about what are<br>
&gt;     &#39;links&#39;. For example, the specification of the VM type contains this:<br>
&gt;<br>
&gt;       @Link DiskAttachment[] diskAttachments();<br>
&gt;       @Link Nic[] nics();<br>
&gt;<br>
&gt;     With this information we are now in a position where we can implement<br>
&gt;     this in a generic way.<br>
&gt;<br>
&gt;     We intend to implement this using a mechanism similar to the existing<br>
&gt;     &#39;detail&#39; parameter:<br>
&gt;<br>
&gt;       GET /ovirt-engine/api/vms/123?foll<wbr>ow=disk_attachments,nics<br>
&gt;<br>
&gt;     The naive implementation of this is to let the API call itself. For<br>
&gt;     example, when the user requests to follow the &#39;disk_attachments&#39; detail<br>
&gt;     the API can just call itself to get that:<br>
&gt;<br>
&gt;       GET /ovirt-engine/api/vms/123/disk<wbr>_attachments<br>
&gt;<br>
&gt;     However, we can&#39;t use that naive approach, if we do we end with the<br>
&gt;     1+C*N query problem described before. We need to use specific<br>
&gt;     implementations for certain frequent use cases, like VMs+disks+nics, and<br>
&gt;     that needs work in the API and in the backend.<br>
&gt;<br>
&gt;     Tomas, if you want to help moving this forward, please open a RFE and<br>
&gt;     makes sure it gets attention.<br></div></div></blockquote><div><br></div></div></div><div>ok, opened: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1436206" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1436206</a></div><div>Will try to get it done soon.</div></div></div></div></blockquote><div><br></div><div>Forgive me if this is radical, but has anyone thought of / discussed using a NoSQL alternative to our very normalized SQL db as a way to avoid the problem of aggregating details? Using mongodb as an example, embed some of the smaller objects, and there&#39;s no cost of aggregation there. IIRC, Doctor REST uses mongo under the hood.<div><br></div><div><a href="https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/">https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/</a><br></div><div><br></div><div>Greg</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-m_-971199036686354921h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">
&gt;<br>
&gt;<br>
&gt; This sounds pretty good! I will open, but since we are talking already<br>
&gt; here I&#39;ll just use the opportunity to clarify the topic more and than<br>
&gt; I&#39;ll open the BZ.<br>
&gt;<br>
&gt; What I can imagine is the GetAllVmsQuery will accept in params also the<br>
&gt; list of details it should provide. Than, the GetAllVmsQuery will<br>
&gt; implement the efficient way of retrieving this info as well.<br>
&gt;<br>
&gt; So, from the API perspective, it will be about taking the<br>
&gt; ?follow=&lt;something&gt; part and passing it to the backend query params.<br>
&gt;<br>
&gt; What you think?<br>
&gt;<br>
<br>
</div></div>Exactly, that is the point! The API by itself can&#39;t optimize database<br>
queries, all it can do is call the backend. It is the backend that has<br>
the opportunity and possibility to send optimized queries to the database.<br>
<br>
For other less common things we can use the naive approach, and<br>
implement the aggregation in the API itself. But for common use cases,<br>
like VM+disks+nics, we need to do it in an efficient way.<br>
<div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5"><br>
&gt;<br>
&gt;<br>
&gt;     2. Reuse of TLS sessions.<br>
&gt;<br>
&gt;     The part of creating TLS sessions that is expensive is the generation of<br>
&gt;     the shared session key. That can be avoided if both the server and the<br>
&gt;     client are careful and reuse the session, using the session cache<br>
&gt;     mechanism built-in into TLS itself. The web servers that we use (Apache<br>
&gt;     and Undertow) do implement this mechanism, and so do most of our<br>
&gt;     clients. Make sure that your client uses it as well. In Java this is<br>
&gt;     achieved re-using the SSLContext. We already do that for the engine to<br>
&gt;     VDSM communciation for example. In JavaScript the browser already takes<br>
&gt;     care of this.<br>
&gt;<br>
&gt;     3. Parallelism and latency.<br>
&gt;<br>
&gt;     A typical problem that we have is that we send many request to the<br>
&gt;     server. For example, to retrieve user sessions for a set of VMs we tend<br>
&gt;     to send many requests like this:<br>
&gt;<br>
&gt;       GET /ovirt-engine/api/vms/1/sessio<wbr>ns<br>
&gt;       GET /ovirt/engine/api/vms/2/sessio<wbr>ns<br>
&gt;       GET /ovirt-engine/api/vms/3/sessio<wbr>ns<br>
&gt;       ...<br>
&gt;<br>
&gt;     And we do that in a synchronous way: send one, wait for the result, send<br>
&gt;     another one, wait for the result, etc. This means that we don&#39;t take<br>
&gt;     advantage of the parallelism of the server and that we add to each<br>
&gt;     request the network round trip time. So if we have N requests, we have<br>
&gt;     to wait at least N*RTT.<br>
&gt;<br>
&gt;     The web servers that we use support multiple connections, and the<br>
&gt;     protocol that we use, HTTP, supports pipe-lining. This means that you<br>
&gt;     can send multiple requests in parallel, and that you can send multiple<br>
&gt;     requests without waiting for the response. To give you an idea of the<br>
&gt;     improvement that can be achieved, we recently added asynchronous request<br>
&gt;     support to the Ruby SDK, with multiple connections and pipe-lining. In<br>
&gt;     our scale testing environment that reduced the time to collect a<br>
&gt;     complete inventory from approx 30 min to approx 2 min. Here you have an<br>
&gt;     example:<br>
&gt;<br>
&gt;<br>
&gt;     <a href="https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/asynchronous_inventory.rb" rel="noreferrer" target="_blank">https://github.com/oVirt/ovir<wbr>t-engine-sdk-ruby/blob/master/<wbr>sdk/examples/asynchronous_inve<wbr>ntory.rb</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/asynchronous_inventory.rb" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-engine-sdk-ruby/blob/master<wbr>/sdk/examples/asynchronous_inv<wbr>entory.rb</a>&gt;<br>
&gt;<br>
&gt;     So make sure that you take advantage of that in your clients. Sadly<br>
&gt;     pipe-lining is disabled by default in most browsers, so this isn&#39;t<br>
&gt;     helpful for JavaScript applications.<br>
&gt;<br>
&gt;<br>
&gt; But we can try what we can do in moVirt about<br>
&gt; this: <a href="https://github.com/oVirt/moVirt/issues/260" rel="noreferrer" target="_blank">https://github.com/oVirt/moVir<wbr>t/issues/260</a><br>
&gt;<br>
<br>
</div></div>Sure, I think there are plenty of asynchronous HTTP clients for Android,<br>
worth trying one of them. If you are brave enough you can even consider<br>
using the same library used in the Ruby SDK: libcurl. A bit of JNI here<br>
and there, and you are done.<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-"><br>
&gt;<br>
&gt;<br>
&gt;     4. HTTP/2 support.<br>
&gt;<br>
&gt;     The application server that we use, WildFly, supports HTTP/2, including<br>
&gt;     ALPN, out of the box, since version 10.1. We need a mechanism to<br>
&gt;     enable it:<br>
&gt;<br>
&gt;       core: Add support for enabling HTTP/2<br>
&gt;       <a href="https://gerrit.ovirt.org/74621" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/7462<wbr>1</a><br>
&gt;<br>
&gt;     And then we need to get Apache out of the way, for API traffic, at<br>
&gt;     least. I think that is something we can do in the context of the engine<br>
&gt;     &quot;podification&quot; effort.<br>
&gt;<br>
&gt;     However, note that HTTP/2 won&#39;t have that big impact in performance for<br>
&gt;     applications that continue to use a synchronous/serial style of<br>
&gt;     interaction with the API.<br>
&gt;<br>
&gt;     On 03/24/2017 11:16 PM, Yaniv Kaul wrote:<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; On Fri, Mar 24, 2017 at 8:57 PM, Martin Sivak &lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;<br>
</span><span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt; &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt; Current Apache used has only experimental module for it.<br>
&gt;     &gt;     &gt; Undertow is supposed to have a better support. I wonder when/if we can drop<br>
&gt;     &gt;     &gt; Apache...<br>
&gt;     &gt;<br>
&gt;     &gt;     The last info I have about that from mperina is that we need Apache<br>
&gt;     &gt;     for kerberos support atm.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; I don&#39;t think we need it - I remember reading that Undertow does support<br>
&gt;     &gt; it as well.<br>
&gt;     &gt; The only issue is that there are probably 10 people in the world who<br>
&gt;     &gt; know how to configure Undertow for Kerberos, while many do for Apache.<br>
&gt;     &gt; And since we leave it for the user to configure...<br>
&gt;     &gt; Y.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     Martin<br>
&gt;     &gt;<br>
&gt;     &gt;     On Fri, Mar 24, 2017 at 5:30 PM, Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> &lt;mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt;<br>
</span><span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &lt;mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a> &lt;mailto:<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; On Fri, Mar 24, 2017 at 6:43 PM, Martin Sivak &lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;<br>
</span><div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">&gt;     &gt;     &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt; 2: you can have more api gateways (e.g. more apis)<br>
&gt;     tailored for<br>
&gt;     &gt;     every<br>
&gt;     &gt;     &gt;&gt; &gt; frontend. I don&#39;t think we need this - the current API serves<br>
&gt;     &gt;     us pretty<br>
&gt;     &gt;     &gt;&gt; &gt; well<br>
&gt;     &gt;     &gt;&gt; &gt; in every FE Im involved in. The only thing which I miss<br>
&gt;     is the data<br>
&gt;     &gt;     &gt;&gt; &gt; aggregation.<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; So it does not serve us well. Aggregation of data is one<br>
&gt;     the usual<br>
&gt;     &gt;     &gt;&gt; points of using the gateway.<br>
&gt;     &gt;     &gt;&gt; Yes microservices are affected by this indeed, but so are<br>
&gt;     we because<br>
&gt;     &gt;     &gt;&gt; implementing the aggregation directly in the current engine<br>
&gt;     API layer<br>
&gt;     &gt;     &gt;&gt; is hard.<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt; So I would go back to the original topic of this thread - do<br>
&gt;     &gt;     some small<br>
&gt;     &gt;     &gt;&gt; &gt; change which has a chance to be merged to the project and<br>
&gt;     helps<br>
&gt;     &gt;     us where<br>
&gt;     &gt;     &gt;&gt; &gt; it<br>
&gt;     &gt;     &gt;&gt; &gt; hurts.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; I&#39;m wondering if very specific additional REST API calls can<br>
&gt;     suffice.<br>
&gt;     &gt;     &gt; For example, a &#39;Get VM + disks + NIC&#39; API call seems<br>
&gt;     reasonable to<br>
&gt;     &gt;     add for<br>
&gt;     &gt;     &gt; the various clients who commonly need it.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; Can a simple HTTP/2 to HTTP/AJP gateway be the simplest<br>
&gt;     solution? Our<br>
&gt;     &gt;     &gt;&gt; Apache might even have a module for it already.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Current Apache used has only experimental module for it.<br>
&gt;     &gt;     &gt; Undertow is supposed to have a better support. I wonder<br>
&gt;     when/if we<br>
&gt;     &gt;     can drop<br>
&gt;     &gt;     &gt; Apache...<br>
&gt;     &gt;     &gt; Y.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; That way you can multiplex all the REST calls using a<br>
&gt;     single tcp<br>
&gt;     &gt;     &gt;&gt; connection (and a single SSL negotiation).<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; A custom SSO enabled service like that might be even better<br>
&gt;     as it<br>
&gt;     &gt;     &gt;&gt; would be able to skip the authentication<br>
&gt;     &gt;     &gt;&gt; layers too and that would lower the engine load. But I am<br>
&gt;     not sure it<br>
&gt;     &gt;     &gt;&gt; is possible with the current codebase.<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; Martin<br>
&gt;     &gt;     &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; On Fri, Mar 24, 2017 at 4:22 PM, Tomas Jelinek<br>
&gt;     &gt;     &lt;<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a> &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>&gt;<br>
</div></div>&gt;     &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a> &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>&gt;&gt;&gt;<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &gt;&gt; wrote:<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt; On Fri, Mar 24, 2017 at 3:58 PM, Martin Sivak<br>
&gt;     &gt;     &lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;<br>
</span><div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">&gt;     &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; I feel like every REST API I&#39;ve ever worked with has<br>
&gt;     had the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; aggregation<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; +<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; projection problem. It&#39;s like we&#39;re trying to use REST<br>
&gt;     as a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; replacement<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; for<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; SQL -- but the logic that executes the &quot;SQL&quot; lives in a<br>
&gt;     &gt;     browser now,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; it<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; used to live on a server close to the DB. And REST isn&#39;t<br>
&gt;     &gt;     expressive<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; for<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; selecting data like SQL is.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; The current industry solution I know about is called API<br>
&gt;     gateway..<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; most of the big players have internal API with lots of low<br>
&gt;     &gt;     level stuff<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; and then couple of external API gateways tailored to<br>
&gt;     what the<br>
&gt;     &gt;     client<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; needs.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; <a href="http://microservices.io/patterns/apigateway.html" rel="noreferrer" target="_blank">http://microservices.io/patter<wbr>ns/apigateway.html</a><br>
&gt;     &lt;<a href="http://microservices.io/patterns/apigateway.html" rel="noreferrer" target="_blank">http://microservices.io/patt<wbr>erns/apigateway.html</a>&gt;<br>
&gt;     &gt;     &lt;<a href="http://microservices.io/patterns/apigateway.html" rel="noreferrer" target="_blank">http://microservices.io/patt<wbr>erns/apigateway.html</a><br>
&gt;     &lt;<a href="http://microservices.io/patterns/apigateway.html" rel="noreferrer" target="_blank">http://microservices.io/patt<wbr>erns/apigateway.html</a>&gt;&gt; (check the backend<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; for frontend section)<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; This trend is also visible when you think about services<br>
&gt;     that<br>
&gt;     &gt;     offer<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; API gateway management and billing like<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; <a href="https://aws.amazon.com/api-gateway/" rel="noreferrer" target="_blank">https://aws.amazon.com/api-gat<wbr>eway/</a><br>
&gt;     &lt;<a href="https://aws.amazon.com/api-gateway/" rel="noreferrer" target="_blank">https://aws.amazon.com/api-g<wbr>ateway/</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://aws.amazon.com/api-gateway/" rel="noreferrer" target="_blank">https://aws.amazon.com/api-g<wbr>ateway/</a><br>
&gt;     &lt;<a href="https://aws.amazon.com/api-gateway/" rel="noreferrer" target="_blank">https://aws.amazon.com/api-g<wbr>ateway/</a>&gt;&gt; or our very own<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; <a href="https://www.3scale.net/" rel="noreferrer" target="_blank">https://www.3scale.net/</a><br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt; right, but the api gateway solves 2 problems:<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt; 1: if you have a microservice architecture it is hard for<br>
&gt;     &gt;     frontend to<br>
&gt;     &gt;     &gt;&gt; &gt; talk<br>
&gt;     &gt;     &gt;&gt; &gt; to 20 different moving services. So the gateway hides this<br>
&gt;     &gt;     complexity<br>
&gt;     &gt;     &gt;&gt; &gt; behind<br>
&gt;     &gt;     &gt;&gt; &gt; it. This is not the problem we have.<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt; 2: you can have more api gateways (e.g. more apis)<br>
&gt;     tailored for<br>
&gt;     &gt;     every<br>
&gt;     &gt;     &gt;&gt; &gt; frontend. I don&#39;t think we need this - the current API serves<br>
&gt;     &gt;     us pretty<br>
&gt;     &gt;     &gt;&gt; &gt; well<br>
&gt;     &gt;     &gt;&gt; &gt; in every FE Im involved in. The only thing which I miss<br>
&gt;     is the data<br>
&gt;     &gt;     &gt;&gt; &gt; aggregation.<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt; So I would go back to the original topic of this thread - do<br>
&gt;     &gt;     some small<br>
&gt;     &gt;     &gt;&gt; &gt; change which has a chance to be merged to the project and<br>
&gt;     helps<br>
&gt;     &gt;     us where<br>
&gt;     &gt;     &gt;&gt; &gt; it<br>
&gt;     &gt;     &gt;&gt; &gt; hurts.<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; Martin<br>
&gt;     &gt;     &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; On Fri, Mar 24, 2017 at 3:47 PM, Greg Sheremeta<br>
&gt;     &gt;     &lt;<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a> &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a>&gt;<br>
</div></div>&gt;     &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a> &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a>&gt;&gt;&gt;<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &gt;&gt; &gt;&gt; wrote:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; I feel like every REST API I&#39;ve ever worked with has had the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; aggregation<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; +<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; projection problem. It&#39;s like we&#39;re trying to use REST as a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; replacement<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; for<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; SQL -- but the logic that executes the &quot;SQL&quot; lives in a<br>
&gt;     &gt;     browser now,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; it<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; used to live on a server close to the DB. And REST isn&#39;t<br>
&gt;     &gt;     expressive<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; for<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; selecting data like SQL is.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; There must be some industry solution to this &quot;I want to do<br>
&gt;     &gt;     SQL over<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; REST&quot;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; problem.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; On Fri, Mar 24, 2017 at 5:54 AM, Martin Sivak<br>
&gt;     &gt;     &lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;<br>
</span>&gt;     &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a> &lt;mailto:<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;&gt;&gt;<br>
<div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; for quite some time I have been more or less<br>
&gt;     involved in<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; development<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; of<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; various UIs for oVirt based entirely on the oVirt&#39;s<br>
&gt;     REST API<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; ranging<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; from<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the quite mature moVirt [1] through some cockpit<br>
&gt;     &gt;     extensions to a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; young<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; experimental user portal replacement [2].<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; oVirt optimizer has the same issue..<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 2: add some tiny service which would just accept a<br>
&gt;     list of<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; queries,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; execute<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; them locally (but using real HTTP requests) and<br>
&gt;     return in one<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; bulk. A<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; naive<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; implementation just to give a sense of what I mean of<br>
&gt;     &gt;     this would<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; shell<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; script getting list of strings like<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &quot;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a><br>
&gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a><br>
&gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a>&gt;&gt;&quot; iterate over<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; them<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; do a curl request for each, mangle the results into one<br>
&gt;     &gt;     string and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; return<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; (credits for this idea to msivak). Easy to implement,<br>
&gt;     &gt;     possibility<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; add<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; also projections later to save some bandwidth. But the<br>
&gt;     &gt;     API would<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; anyway<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; hammered by bunch of queries, only the network<br>
&gt;     roundtrip<br>
&gt;     &gt;     would be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; saved.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; The biggest cost for (especially mobile) clients is<br>
&gt;     the cost of<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; establishing new SSL connection. SSL is also pretty<br>
&gt;     &gt;     expensive on the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; server side.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; So running the aggregation service on the<br>
&gt;     ovirt-engine machine<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; (behind<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; Apache) means the client will do a single SSL request<br>
&gt;     with<br>
&gt;     &gt;     list of N<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; urls and the local &quot;reverse-proxy&quot; will perform single<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; authentication<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; and N plain HTTP requests (or even better - AJP). It<br>
&gt;     won&#39;t<br>
&gt;     &gt;     remove<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; any<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; time from the actual command run time, but it will reduce<br>
&gt;     &gt;     protocol<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; overhead.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; I think this is the simplest first step that requires<br>
&gt;     almost no<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; change<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; to existing infrastructure.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; --<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; Martin Sivak<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; SLA / oVirt<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; On Fri, Mar 24, 2017 at 10:20 AM, Tomas Jelinek<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a> &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>&gt;<br>
</div></div>&gt;     &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a> &lt;mailto:<a href="mailto:tjelinek@redhat.com" target="_blank">tjelinek@redhat.com</a>&gt;&gt;&gt;<br>
<div><div class="gmail-m_-971199036686354921m_4462347545091815787gmail-h5">&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; wrote:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Hi All,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; for quite some time I have been more or less<br>
&gt;     involved in<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; development<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; of<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; various UIs for oVirt based entirely on the oVirt&#39;s<br>
&gt;     REST API<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; ranging<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; from<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the quite mature moVirt [1] through some cockpit<br>
&gt;     &gt;     extensions to a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; young<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; experimental user portal replacement [2].<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; One issue we hit over and over again is the missing<br>
&gt;     data<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; aggregation.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; In<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 3.x era we used to use in moVirt the detail=something<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; api to get the disks and nics of the VM, something<br>
&gt;     like:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; GET /ovirt-engine/api/vms<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Accept: application/json; detail=disks<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; This allowed us to store this data in local database<br>
&gt;     &gt;     leading to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; great<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; user<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; experience. Since this feature has been removed in 4.x<br>
&gt;     &gt;     API [3]<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; we needed to retire to a different solution. When<br>
&gt;     the VM<br>
&gt;     &gt;     detail is<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; selected<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; by the user, start loading the disks and nics and hope<br>
&gt;     &gt;     the user<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; will not be fast enough to see the delay. The UX is<br>
&gt;     &gt;     slightly worse<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; bug<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; kinda<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; acceptable.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; We hit this issue harder in the new user portal [2],<br>
&gt;     &gt;     because we<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; already<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; have<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the VM cached and show the whole VM in one screen.<br>
&gt;     So, if<br>
&gt;     &gt;     you pick<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; it,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; you<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; will get it&#39;s details immediately.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; But, since you don&#39;t have all the details, we need<br>
&gt;     to do an<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; additional<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; call<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; (two actually) to load this data and they start to<br>
&gt;     appear<br>
&gt;     &gt;     later.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; So, something which would be very fast and smooth<br>
&gt;     starts<br>
&gt;     &gt;     to feel<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; sluggish.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Recently, we hit this issue again which forced us to<br>
&gt;     &gt;     sacrifice the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; UX<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; even<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; more - it is the &quot;console in use&quot; feature of user<br>
&gt;     portal.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; The use case is this:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - if the console is already taken by some user,<br>
&gt;     there are<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; complications<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; if<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; other current user tryes to take it as well (will avoid<br>
&gt;     &gt;     details<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; about<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; settings and permissins involved, but long story short,<br>
&gt;     &gt;     the user<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; will<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; probably not be allowed to connect to it. The<br>
&gt;     &quot;probably&quot;<br>
&gt;     &gt;     is the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; key<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; here<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; since we can not do any intelligent decision in<br>
&gt;     advance,<br>
&gt;     &gt;     we can<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; only<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; warn<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the user that the console is taken).<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - in the current GWT user portal, if the VM&#39;s<br>
&gt;     console is<br>
&gt;     &gt;     taken, it<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; is<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; shown<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; on the VM&#39;s &quot;box&quot; that &quot;console is taken&quot;. This was<br>
&gt;     a highly<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; requested<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; feature<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - to get this information using the current REST<br>
&gt;     API, we<br>
&gt;     &gt;     need to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; go<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; /vms/&lt;vmid&gt;/sessions subcollection. To get this for all<br>
&gt;     &gt;     VMs, it<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; would<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; doing N queries per poll which we can not afford<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - so the current PR [4] will probably end up to only<br>
&gt;     &gt;     check it on<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; attempt<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to connect to the console warning the user. Maybe<br>
&gt;     it will<br>
&gt;     &gt;     be also<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; shown<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; in<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Vm details. But the UX in case the user will look for a<br>
&gt;     &gt;     VM which<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; has<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; free<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; console will suffer significantly (e.g. try one by one<br>
&gt;     &gt;     until some<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; opens<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; or<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; look at details one by one to see if the warning<br>
&gt;     appears<br>
&gt;     &gt;     (with a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; delay))<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; I understand that embedding the details of the VM<br>
&gt;     to the<br>
&gt;     &gt;     response<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; comes<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; with<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; a cost, namely:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - performance hit<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - complexity of the API code<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - the &quot;cleanness&quot; of REST suffers<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; But I think we should seriously consider to provide<br>
&gt;     some<br>
&gt;     &gt;     option to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; data<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; aggregation.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; I know this has been discussed many times with no<br>
&gt;     result,<br>
&gt;     &gt;     but I<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; think<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; it<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; is<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; time to bring this topic up again. I&#39;ll try to<br>
&gt;     summarize the<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; (failed)<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; attempts tried so far:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - the detail=&lt;something&gt; parameter with ad-hoc<br>
&gt;     embedding<br>
&gt;     &gt;     of data.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; This<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; has<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; been there and removed in 4.0 [3]<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - the DoctorREST project - e.g. a proxy above the<br>
&gt;     current<br>
&gt;     &gt;     api. The<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; idea<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; was<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to create a service which will be independent of<br>
&gt;     the engine<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; itself,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; will<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; locally poll the engine&#39;s REST, store all data in local<br>
&gt;     &gt;     (mongo)DB<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; provide a rich api with aggregations and<br>
&gt;     projections and push<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; notifications.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; This polling of everything to get the data to<br>
&gt;     DoctorREST<br>
&gt;     &gt;     proved to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; pretty<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; costy, so also a more invasive approach of pushing<br>
&gt;     data from<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; engine<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; doctor has been discused [5]. None of this two<br>
&gt;     approaches<br>
&gt;     &gt;     have<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; been<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; accepted<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; (too complicated, too invasive).<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - writing some custom ad-hoc servlet serving only a<br>
&gt;     &gt;     purpose of one<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; frontend<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - this is actually there for the dashboard, but it<br>
&gt;     is not a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; generic<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; solution<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; for the other frontends and we really should not<br>
&gt;     develop<br>
&gt;     &gt;     custom<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; &quot;APIs&quot;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; for<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; every frontend<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; - there were some other proposals discussed (some<br>
&gt;     3th party<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; solutions<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; etc)<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; but I think none of them made it even to a PoC<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; So, now I would try again and try small to get at<br>
&gt;     least some<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; benefit.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; I<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; see<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 2 paths we could try:<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 1: embed something which burns us immediatly, e.g. the<br>
&gt;     &gt;     /sessions<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; into<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; VMs. I<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; really liked the ;detail=sessions approach, could<br>
&gt;     we move<br>
&gt;     &gt;     it back?<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 2: add some tiny service which would just accept a<br>
&gt;     list of<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; queries,<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; execute<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; them locally (but using real HTTP requests) and<br>
&gt;     return in one<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; bulk. A<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; naive<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; implementation just to give a sense of what I mean of<br>
&gt;     &gt;     this would<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be a<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; shell<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; script getting list of strings like<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &quot;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a><br>
&gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a><br>
&gt;     &lt;<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-engi<wbr>ne/api/vms/123/sessions</a>&gt;&gt;&quot; iterate over<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; them<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; do a curl request for each, mangle the results into one<br>
&gt;     &gt;     string and<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; return<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; (credits for this idea to msivak). Easy to implement,<br>
&gt;     &gt;     possibility<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; to<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; add<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; also projections later to save some bandwidth. But the<br>
&gt;     &gt;     API would<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; anyway<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; hammered by bunch of queries, only the network<br>
&gt;     roundtrip<br>
&gt;     &gt;     would be<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; saved.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; 3: any other simple approaches?<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; I honestly prefer the first approach. It is not<br>
&gt;     &gt;     beautiful, it is<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; not<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; REST-ful, but it is easy to implement, very<br>
&gt;     pragmatic and<br>
&gt;     &gt;     useful.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; What do you think?<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Thank you and sorry for the long mail :)<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Tomas<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; [1]: <a href="https://github.com/oVirt/moVirt" rel="noreferrer" target="_blank">https://github.com/oVirt/moVir<wbr>t</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/moVirt" rel="noreferrer" target="_blank">https://github.com/oVirt/moV<wbr>irt</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://github.com/oVirt/moVirt" rel="noreferrer" target="_blank">https://github.com/oVirt/moV<wbr>irt</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/moVirt" rel="noreferrer" target="_blank">https://github.com/oVirt/moV<wbr>irt</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; [2]: <a href="https://github.com/oVirt/ovirt-web-ui" rel="noreferrer" target="_blank">https://github.com/oVirt/ovirt<wbr>-web-ui</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; [3]: <a href="https://gerrit.ovirt.org/#/c/61260" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/6<wbr>1260</a><br>
&gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/61260" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/61260</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/61260" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/61260</a><br>
&gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/61260" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/61260</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; [4]:<br>
&gt;     <a href="https://github.com/oVirt/ovirt-web-ui/pull/106/" rel="noreferrer" target="_blank">https://github.com/oVirt/ovir<wbr>t-web-ui/pull/106/</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui/pull/106/" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui/pull/106/</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui/pull/106/" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui/pull/106/</a><br>
&gt;     &lt;<a href="https://github.com/oVirt/ovirt-web-ui/pull/106/" rel="noreferrer" target="_blank">https://github.com/oVirt/ovi<wbr>rt-web-ui/pull/106/</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; [5]: <a href="https://gerrit.ovirt.org/#/c/45233/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/4<wbr>5233/</a><br>
&gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/45233/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/45233/</a>&gt;<br>
&gt;     &gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/45233/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/45233/</a><br>
&gt;     &lt;<a href="https://gerrit.ovirt.org/#/c/45233/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c<wbr>/45233/</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; ______________________________<wbr>_________________<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; Devel mailing list<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;<br>
</div></div>&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;&gt;<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;<br>
&gt;     &gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; ______________________________<wbr>_________________<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; Devel mailing list<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;<br>
</span>&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; --<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; Greg Sheremeta, MBA<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; Red Hat, Inc.<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; Sr. Software Engineer<br>
&gt;     &gt;     &gt;&gt; &gt;&gt; &gt; <a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a> &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a>&gt;<br>
</span>&gt;     &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a> &lt;mailto:<a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a>&gt;&gt;<br>
<span class="gmail-m_-971199036686354921m_4462347545091815787gmail-">&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; &gt;<br>
&gt;     &gt;     &gt;&gt; ______________________________<wbr>_________________<br>
&gt;     &gt;     &gt;&gt; Devel mailing list<br>
&gt;     &gt;     &gt;&gt; <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;<br>
</span>&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;<br>
&gt;     &gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a><br>
&gt;     &lt;<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailm<wbr>an/listinfo/devel</a>&gt;&gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;<br>
&gt;<br>
<br>
</blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-971199036686354921gmail_signature"><div dir="ltr"><div>Greg Sheremeta, MBA<br>Red Hat, Inc.<br>Sr. Software Engineer<br><a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a><br></div></div></div>
</div></div></div>