On Thu, Oct 3, 2013 at 4:18 PM, Daan Hoogland <daan.hoogl...@gmail.com>wrote:
> 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? > > > Generally as a principle core API's abstract and expose functionality that is commonly available across the hypervisors and network service providers etc.. I believe we should continue to enforce it. But we do have a pattern of API's configure* (configurevirtualrouter, configurenetscaler etc) where a hypervisor/network element plug-in can let admin to configure params specific to plug-in. Perhaps we can use this API's fine tune a plugin for advanced configurations. For e.g both HaProxy max connections, httpModeEnabled can be parameters that can be configured with configureVirtualRouter api. Daan, does this approach works for you? -Murali > > 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. > > > > > > >
