> On Oct 3, 2013, at 3:01 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> > wrote: > > I was thinking along the same lines that a offering could have a generic > key/value map (where the value could be a string/json string/whatever). > CloudStack core wouldn't have any idea about the semantics of the keys or > values, but the specific hypervisor/provider might decide to interpret it.
+1 - a model for extensions like that makes perfect sense. > > >> On 10/3/13 11:15 AM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >> >> 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. >>>>>> >>>>>> >>>>>> >>>>> >>>> > >
