On 04/10/13 12:32 AM, "Chip Childers" <chip.child...@sungard.com> wrote:
>> 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. We already have api's (add/list/removeResourceDetails) in 4.2 [1] to add key-value metadata to first class objects of CloudStack. At present it does not have semantic meaning to neither core nor plug-ins, but should not be hard to extend so that plug-ins can access meta-data and interpret it. [1] http://s.apache.org/ReK > >> >> >>> 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. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >> >> >
