We are always going to run into the issue where they're implementation specific features that can't be represented in a generic way in the API. First class attributes in the API need to essentially be the lowest common denominator. ACS already has this pattern of *_details tables. I honestly don't know completely how they are used, but I would hope that pattern could be used to address these types of issues. By allowing the admin to add arbitrary key/value pairs to the various offerings/entities we can use that to tap into provider specific or advanced configuration. For the http close proposal you could just add haproxy.httpClose=true on the network offering and the haproxy impl can respect that and use it. So implementations can document what additional key/value parameters they support to access advanced features.
Review 13896 adds an otherOptions field to the service offering. Conceptually that is fine in my mind, but I just don't understand why the *_details tables can't be used instead. Just like XenServer has other_config on all types, I'd like it if ACS had a similar thing (which I kinda, sorta think it does?). So we should be able to arbitrary data onto any type. Can somebody comment on how this idea may relate with the existing implementation of "details" and "tags" in ACS? Darren On Thu, Oct 3, 2013 at 10:21 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > Murali, > > What our admins need is the ability to instantiate an abstract thing called > a virtual redundant high available router. They need be able to tune it > with all sorts of features is such a way that other routers redundant or > not and high availible or not, may but do not have to have the same tuning > parameters. This 'feature' of httpClose is just one of the many things they > need to be able to tune. Others include a more fine grained control over > the iptables/firewall rules and monitoring of the functionality/daemons > running on the machines. I am not biased as to the way how to do/implement > this control. The networkoffering seemed like the way to do it. > > Having said that I didn't think that httpClose would be considered haproxy > specific. It seems worrying that someone could device a proxy or a > loadbalancer that does not support either one of the features of > maximizing - or pooling connections. I'm not into that market recently so I > might be mistaking. This maybe besides the point but it discomforts me > somewhat. > > regards, > Daan > > > On Thu, Oct 3, 2013 at 2:22 PM, murali reddy <muralimmre...@gmail.com>wrote: > >> 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. >> > > >> > > >> > > >> > >>
