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.
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. >>> > > >>> > > >>> > > >>> > >>>
