Can we discuss the folowing: Some type of device, the flutch is widely used and cloudstack supports brands a and b. Now brand c comes to the market with feature X. It grows it's market share slowly becouse of this feature and we, or better the producer implement a plugin using the new resourcedetails pattern. Now the market share starts growing as people start realizing that a flutch without X makes no sense. a and b implement X in their flutches. the cloudstack user does now have to configure for his legacy a and b flutches as wel as for his brand new flying c, X as a key value pair on each device. we want to accomodat this by making X a standard part of the flutch-offering, don't we?
Even if a decides to implement X in their flutches but b doesn't I think we would want to do that. It may come as now surprise that, given the test results the Schuberg Philis engineers produced and put in https://issues.apache.org/jira/browse/CLOUDSTACK-4328, I feel the httpClose feature in an X with respect to loadbalancers and proxies. kind regards, Daan On Fri, Oct 4, 2013 at 7:52 AM, Murali Reddy <murali.re...@citrix.com>wrote: > 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. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >> > >> > > > > >
