<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 6:43 PM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 2: you can have more api gateways (e.g. more apis) tailored for every<br>
> frontend. I don't think we need this - the current API serves us pretty well<br>
> in every FE Im involved in. The only thing which I miss is the data<br>
> aggregation.<br>
<br>
</span>So it does not serve us well. Aggregation of data is one the usual<br>
points of using the gateway.<br>
Yes microservices are affected by this indeed, but so are we because<br>
implementing the aggregation directly in the current engine API layer<br>
is hard.<br>
<span class=""><br>
> So I would go back to the original topic of this thread - do some small<br>
> change which has a chance to be merged to the project and helps us where it<br>
> hurts.<br></span></blockquote><div><br></div><div>I'm wondering if very specific additional REST API calls can suffice.</div><div>For example, a 'Get VM + disks + NIC' API call seems reasonable to add for the various clients who commonly need it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Can a simple HTTP/2 to HTTP/AJP gateway be the simplest solution? Our<br>
Apache might even have a module for it already.<br></blockquote><div><br></div><div>Current Apache used has only experimental module for it.</div><div>Undertow is supposed to have a better support. I wonder when/if we can drop Apache...</div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That way you can multiplex all the REST calls using a single tcp<br>
connection (and a single SSL negotiation).<br>
<br>
A custom SSO enabled service like that might be even better as it<br>
would be able to skip the authentication<br>
layers too and that would lower the engine load. But I am not sure it<br>
is possible with the current codebase.<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 24, 2017 at 4:22 PM, Tomas Jelinek <<a href="mailto:tjelinek@redhat.com">tjelinek@redhat.com</a>> wrote:<br>
><br>
><br>
> On Fri, Mar 24, 2017 at 3:58 PM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>><br>
>> > I feel like every REST API I've ever worked with has had the aggregation<br>
>> > +<br>
>> > projection problem. It's like we're trying to use REST as a replacement<br>
>> > for<br>
>> > SQL -- but the logic that executes the "SQL" lives in a browser now, and<br>
>> > it<br>
>> > used to live on a server close to the DB. And REST isn't expressive for<br>
>> > selecting data like SQL is.<br>
>><br>
>> The current industry solution I know about is called API gateway..<br>
>> most of the big players have internal API with lots of low level stuff<br>
>> and then couple of external API gateways tailored to what the client<br>
>> needs.<br>
>><br>
>> <a href="http://microservices.io/patterns/apigateway.html" rel="noreferrer" target="_blank">http://microservices.io/<wbr>patterns/apigateway.html</a> (check the backend<br>
>> for frontend section)<br>
>><br>
>> This trend is also visible when you think about services that offer<br>
>> API gateway management and billing like<br>
>> <a href="https://aws.amazon.com/api-gateway/" rel="noreferrer" target="_blank">https://aws.amazon.com/api-<wbr>gateway/</a> or our very own<br>
>> <a href="https://www.3scale.net/" rel="noreferrer" target="_blank">https://www.3scale.net/</a><br>
><br>
><br>
> right, but the api gateway solves 2 problems:<br>
><br>
> 1: if you have a microservice architecture it is hard for frontend to talk<br>
> to 20 different moving services. So the gateway hides this complexity behind<br>
> it. This is not the problem we have.<br>
><br>
> 2: you can have more api gateways (e.g. more apis) tailored for every<br>
> frontend. I don't think we need this - the current API serves us pretty well<br>
> in every FE Im involved in. The only thing which I miss is the data<br>
> aggregation.<br>
><br>
> So I would go back to the original topic of this thread - do some small<br>
> change which has a chance to be merged to the project and helps us where it<br>
> hurts.<br>
><br>
>><br>
>><br>
>><br>
>> Martin<br>
>><br>
>> On Fri, Mar 24, 2017 at 3:47 PM, Greg Sheremeta <<a href="mailto:gshereme@redhat.com">gshereme@redhat.com</a>><br>
>> wrote:<br>
>> > I feel like every REST API I've ever worked with has had the aggregation<br>
>> > +<br>
>> > projection problem. It's like we're trying to use REST as a replacement<br>
>> > for<br>
>> > SQL -- but the logic that executes the "SQL" lives in a browser now, and<br>
>> > it<br>
>> > used to live on a server close to the DB. And REST isn't expressive for<br>
>> > selecting data like SQL is.<br>
>> ><br>
>> > There must be some industry solution to this "I want to do SQL over<br>
>> > REST"<br>
>> > problem.<br>
>> ><br>
>> > On Fri, Mar 24, 2017 at 5:54 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>> >><br>
>> >> > for quite some time I have been more or less involved in development<br>
>> >> > of<br>
>> >> > various UIs for oVirt based entirely on the oVirt's REST API ranging<br>
>> >> > from<br>
>> >> > the quite mature moVirt [1] through some cockpit extensions to a<br>
>> >> > young<br>
>> >> > and<br>
>> >> > experimental user portal replacement [2].<br>
>> >><br>
>> >> oVirt optimizer has the same issue..<br>
>> >><br>
>> >> > 2: add some tiny service which would just accept a list of queries,<br>
>> >> > execute<br>
>> >> > them locally (but using real HTTP requests) and return in one bulk. A<br>
>> >> > naive<br>
>> >> > implementation just to give a sense of what I mean of this would be a<br>
>> >> > shell<br>
>> >> > script getting list of strings like<br>
>> >> > "<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-<wbr>engine/api/vms/123/sessions</a>" iterate over<br>
>> >> > them<br>
>> >> > and<br>
>> >> > do a curl request for each, mangle the results into one string and<br>
>> >> > return<br>
>> >> > (credits for this idea to msivak). Easy to implement, possibility to<br>
>> >> > add<br>
>> >> > also projections later to save some bandwidth. But the API would<br>
>> >> > anyway<br>
>> >> > be<br>
>> >> > hammered by bunch of queries, only the network roundtrip would be<br>
>> >> > saved.<br>
>> >><br>
>> >> The biggest cost for (especially mobile) clients is the cost of<br>
>> >> establishing new SSL connection. SSL is also pretty expensive on the<br>
>> >> server side.<br>
>> >><br>
>> >> So running the aggregation service on the ovirt-engine machine (behind<br>
>> >> Apache) means the client will do a single SSL request with list of N<br>
>> >> urls and the local "reverse-proxy" will perform single authentication<br>
>> >> and N plain HTTP requests (or even better - AJP). It won't remove any<br>
>> >> time from the actual command run time, but it will reduce protocol<br>
>> >> overhead.<br>
>> >><br>
>> >> I think this is the simplest first step that requires almost no change<br>
>> >> to existing infrastructure.<br>
>> >><br>
>> >> --<br>
>> >> Martin Sivak<br>
>> >> SLA / oVirt<br>
>> >><br>
>> >> On Fri, Mar 24, 2017 at 10:20 AM, Tomas Jelinek <<a href="mailto:tjelinek@redhat.com">tjelinek@redhat.com</a>><br>
>> >> wrote:<br>
>> >> > Hi All,<br>
>> >> ><br>
>> >> > for quite some time I have been more or less involved in development<br>
>> >> > of<br>
>> >> > various UIs for oVirt based entirely on the oVirt's REST API ranging<br>
>> >> > from<br>
>> >> > the quite mature moVirt [1] through some cockpit extensions to a<br>
>> >> > young<br>
>> >> > and<br>
>> >> > experimental user portal replacement [2].<br>
>> >> ><br>
>> >> > One issue we hit over and over again is the missing data aggregation.<br>
>> >> > In<br>
>> >> > the<br>
>> >> > 3.x era we used to use in moVirt the detail=something<br>
>> >> > api to get the disks and nics of the VM, something like:<br>
>> >> ><br>
>> >> > GET /ovirt-engine/api/vms<br>
>> >> > Accept: application/json; detail=disks<br>
>> >> ><br>
>> >> > This allowed us to store this data in local database leading to great<br>
>> >> > user<br>
>> >> > experience. Since this feature has been removed in 4.x API [3]<br>
>> >> > we needed to retire to a different solution. When the VM detail is<br>
>> >> > selected<br>
>> >> > by the user, start loading the disks and nics and hope the user<br>
>> >> > will not be fast enough to see the delay. The UX is slightly worse<br>
>> >> > bug<br>
>> >> > kinda<br>
>> >> > acceptable.<br>
>> >> ><br>
>> >> > We hit this issue harder in the new user portal [2], because we<br>
>> >> > already<br>
>> >> > have<br>
>> >> > the VM cached and show the whole VM in one screen. So, if you pick<br>
>> >> > it,<br>
>> >> > you<br>
>> >> > will get it's details immediately.<br>
>> >> > But, since you don't have all the details, we need to do an<br>
>> >> > additional<br>
>> >> > call<br>
>> >> > (two actually) to load this data and they start to appear later.<br>
>> >> > So, something which would be very fast and smooth starts to feel<br>
>> >> > sluggish.<br>
>> >> ><br>
>> >> > Recently, we hit this issue again which forced us to sacrifice the UX<br>
>> >> > even<br>
>> >> > more - it is the "console in use" feature of user portal.<br>
>> >> > The use case is this:<br>
>> >> > - if the console is already taken by some user, there are<br>
>> >> > complications<br>
>> >> > if<br>
>> >> > other current user tryes to take it as well (will avoid details about<br>
>> >> > settings and permissins involved, but long story short, the user will<br>
>> >> > probably not be allowed to connect to it. The "probably" is the key<br>
>> >> > here<br>
>> >> > since we can not do any intelligent decision in advance, we can only<br>
>> >> > warn<br>
>> >> > the user that the console is taken).<br>
>> >> > - in the current GWT user portal, if the VM's console is taken, it is<br>
>> >> > shown<br>
>> >> > on the VM's "box" that "console is taken". This was a highly<br>
>> >> > requested<br>
>> >> > feature<br>
>> >> > - to get this information using the current REST API, we need to go<br>
>> >> > to<br>
>> >> > the<br>
>> >> > /vms/<vmid>/sessions subcollection. To get this for all VMs, it would<br>
>> >> > be<br>
>> >> > doing N queries per poll which we can not afford<br>
>> >> > - so the current PR [4] will probably end up to only check it on the<br>
>> >> > attempt<br>
>> >> > to connect to the console warning the user. Maybe it will be also<br>
>> >> > shown<br>
>> >> > in<br>
>> >> > Vm details. But the UX in case the user will look for a VM which has<br>
>> >> > free<br>
>> >> > console will suffer significantly (e.g. try one by one until some<br>
>> >> > opens<br>
>> >> > or<br>
>> >> > look at details one by one to see if the warning appears (with a<br>
>> >> > delay))<br>
>> >> ><br>
>> >> > I understand that embedding the details of the VM to the response<br>
>> >> > comes<br>
>> >> > with<br>
>> >> > a cost, namely:<br>
>> >> > - performance hit<br>
>> >> > - complexity of the API code<br>
>> >> > - the "cleanness" of REST suffers<br>
>> >> ><br>
>> >> > But I think we should seriously consider to provide some option to<br>
>> >> > data<br>
>> >> > aggregation.<br>
>> >> ><br>
>> >> > I know this has been discussed many times with no result, but I think<br>
>> >> > it<br>
>> >> > is<br>
>> >> > time to bring this topic up again. I'll try to summarize the (failed)<br>
>> >> > attempts tried so far:<br>
>> >> > - the detail=<something> parameter with ad-hoc embedding of data.<br>
>> >> > This<br>
>> >> > has<br>
>> >> > been there and removed in 4.0 [3]<br>
>> >> > - the DoctorREST project - e.g. a proxy above the current api. The<br>
>> >> > idea<br>
>> >> > was<br>
>> >> > to create a service which will be independent of the engine itself,<br>
>> >> > will<br>
>> >> > locally poll the engine's REST, store all data in local (mongo)DB and<br>
>> >> > provide a rich api with aggregations and projections and push<br>
>> >> > notifications.<br>
>> >> > This polling of everything to get the data to DoctorREST proved to be<br>
>> >> > pretty<br>
>> >> > costy, so also a more invasive approach of pushing data from engine<br>
>> >> > to<br>
>> >> > doctor has been discused [5]. None of this two approaches have been<br>
>> >> > accepted<br>
>> >> > (too complicated, too invasive).<br>
>> >> > - writing some custom ad-hoc servlet serving only a purpose of one<br>
>> >> > frontend<br>
>> >> > - this is actually there for the dashboard, but it is not a generic<br>
>> >> > solution<br>
>> >> > for the other frontends and we really should not develop custom<br>
>> >> > "APIs"<br>
>> >> > for<br>
>> >> > every frontend<br>
>> >> > - there were some other proposals discussed (some 3th party solutions<br>
>> >> > etc)<br>
>> >> > but I think none of them made it even to a PoC<br>
>> >> ><br>
>> >> > So, now I would try again and try small to get at least some benefit.<br>
>> >> > I<br>
>> >> > see<br>
>> >> > 2 paths we could try:<br>
>> >> > 1: embed something which burns us immediatly, e.g. the /sessions into<br>
>> >> > VMs. I<br>
>> >> > really liked the ;detail=sessions approach, could we move it back?<br>
>> >> > 2: add some tiny service which would just accept a list of queries,<br>
>> >> > execute<br>
>> >> > them locally (but using real HTTP requests) and return in one bulk. A<br>
>> >> > naive<br>
>> >> > implementation just to give a sense of what I mean of this would be a<br>
>> >> > shell<br>
>> >> > script getting list of strings like<br>
>> >> > "<a href="https://localhost/ovirt-engine/api/vms/123/sessions" rel="noreferrer" target="_blank">https://localhost/ovirt-<wbr>engine/api/vms/123/sessions</a>" iterate over<br>
>> >> > them<br>
>> >> > and<br>
>> >> > do a curl request for each, mangle the results into one string and<br>
>> >> > return<br>
>> >> > (credits for this idea to msivak). Easy to implement, possibility to<br>
>> >> > add<br>
>> >> > also projections later to save some bandwidth. But the API would<br>
>> >> > anyway<br>
>> >> > be<br>
>> >> > hammered by bunch of queries, only the network roundtrip would be<br>
>> >> > saved.<br>
>> >> > 3: any other simple approaches?<br>
>> >> ><br>
>> >> > I honestly prefer the first approach. It is not beautiful, it is not<br>
>> >> > REST-ful, but it is easy to implement, very pragmatic and useful.<br>
>> >> > What do you think?<br>
>> >> ><br>
>> >> > Thank you and sorry for the long mail :)<br>
>> >> > Tomas<br>
>> >> ><br>
>> >> > [1]: <a href="https://github.com/oVirt/moVirt" rel="noreferrer" target="_blank">https://github.com/oVirt/<wbr>moVirt</a><br>
>> >> > [2]: <a href="https://github.com/oVirt/ovirt-web-ui" rel="noreferrer" target="_blank">https://github.com/oVirt/<wbr>ovirt-web-ui</a><br>
>> >> > [3]: <a href="https://gerrit.ovirt.org/#/c/61260" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>61260</a><br>
>> >> > [4]: <a href="https://github.com/oVirt/ovirt-web-ui/pull/106/" rel="noreferrer" target="_blank">https://github.com/oVirt/<wbr>ovirt-web-ui/pull/106/</a><br>
>> >> > [5]: <a href="https://gerrit.ovirt.org/#/c/45233/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>45233/</a><br>
>> >> ><br>
>> >> ><br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > Devel mailing list<br>
>> >> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Devel mailing list<br>
>> >> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Greg Sheremeta, MBA<br>
>> > Red Hat, Inc.<br>
>> > Sr. Software Engineer<br>
>> > <a href="mailto:gshereme@redhat.com">gshereme@redhat.com</a><br>
><br>
><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>