cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]
Date Thu, 03 Oct 2013 19:02:34 GMT
> On Oct 3, 2013, at 3:01 PM, Chiradeep Vittal <> 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" <> 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 <>
>> 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
>>> <>wrote:
>>>> On Thu, Oct 3, 2013 at 4:18 PM, Daan Hoogland <
>>>>> wrote:
>>>>> Chiradeep,
>>>>> I have been thinking about your concern and there is something
>>>> bothering
>>>> me
>>>>> about it. The issue CLOUDSTACK-4328 of which
>>>>> 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 <
>>>>>> 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
>>>>>> 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.

View raw message