Chiradeep, I have been thinking about your concern and there is something bothering me about it. The issue CLOUDSTACK-4328 of which https://reviews.apache.org/r/14320/ is an implementation. This issue has been brought up by the engineers at Schuberg Philis. These are cloud operators and domain admins. So these are the people that need to be bothered by this tuning and they are certainly haproxy and xen experts to an extend. For them not being able to use connection caching was a bug. And the proposed solution still seems reasonable to me. It is exposing the abstract feature only to those instantiating a vpc, isn't it? This last question probably touches on the reason you are addressing my submission together with the ones from Nicolas I see only people instantiating a vpc having to be bothered by which netoffering to use (with respect to httpClose functionality) If this is not the case how should I isolate this concern from other , more mondain users?
btw I did not create an FS page as the issue was created as a jira ticket. I am willing to do that in hind sight but want to have a path to follow first. regards, Daan On Tue, Oct 1, 2013 at 11:06 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > > We have a couple of people trying to expose the advanced capabilities of the underlying physical resources to the end-user. In the case of Nicolas FOATA, he is trying to expose some of the advanced functions of XenServer/XCP, and in the case of Daan, he is trying to expose some feature of HAProxy. > > Users are ideally abstracted from these details and shouldn't have to wonder which offering to choose [because they are not Xen/HAProxy experts]. > After all one of the goals of CS is to hide these messy details and let users focus on their apps. > > Is there a possibility of a generic way of leaking abstractions for sufficiently advanced users? > > https://reviews.apache.org/r/13238/ > https://reviews.apache.org/r/14320/ > https://reviews.apache.org/r/13896/ > > BTW, I really prefer that these changes are discussed by putting up an FS on the wiki rather than submitting patch requests. > If it touches more than a few files, it is probably worth discussing with a [DISCUSS] tag line. > Also, it requires tests. > > >
